From rstruik.ext@gmail.com Mon Dec 2 06:28:38 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8000D1AE437 for ; Mon, 2 Dec 2013 06:28:38 -0800 (PST) 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 q6_dANloPzCg for ; Mon, 2 Dec 2013 06:28:36 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2071AE434 for ; Mon, 2 Dec 2013 06:28:36 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id to1so20785973ieb.18 for ; Mon, 02 Dec 2013 06:28:34 -0800 (PST) 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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3I9evhpX5corq9fQGuP/1TQRwFlifBhDlINIYKwYKlo=; b=sH/UX5dq1Nm/FCwquGPlqdHnWzXp4Y3Vxw3tGQ/dcVSje6vI69Do8FNsTHSYUPV3Lc qQtkBvVet9W30TqZY/obGNIb195tC9BDHbscGZ0R2hicc3ZUhaFq+bnTkAhePk+h9DGR 5Vz/VtHTiLHHaVI8x0Y2gR5LPs34kzOtNpBWMaTsgVo231WCDVfZF2V5XhxeVrYJfIfM Z1niqN26dwF/Y5K8/UZsQIyZBOS1nDeAgmC3PJEPCVcEe3Y6ZnhTtIbnBjJt4LGPfDQj APr2PpQc36G2ur14ZjlunrWBUuQU78jPKSsL+I2PDUdYCCM8B7PTHhkg6dlirXRaLghz vXLw== X-Received: by 10.50.67.99 with SMTP id m3mr17799573igt.35.1385994514030; Mon, 02 Dec 2013 06:28:34 -0800 (PST) Received: from [192.168.1.102] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.230.254.17]) by mx.google.com with ESMTPSA id da14sm26576978igc.1.2013.12.02.06.28.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 06:28:32 -0800 (PST) Message-ID: <529C990D.3020608@gmail.com> Date: Mon, 02 Dec 2013 09:28:29 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" , "" References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> In-Reply-To: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2013 14:28:38 -0000 Dear colleagues: I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work that went into this draft, I have to concur with some other commenters (e.g., Doug Stebila, Bodo Moeller) that it is unclear what makes this protocol special compared to other contenders, both in terms of performance and detailed cryptanalysis. One glaring omission is detailed security evidence, which is currently lacking (cross-referencing some other standards that have specified the protocol does not by itself imply the protocol is therefore secure). I am kind of curious what technical advantages the "Dragonfly" protocol has over protocols that seem to have efficiency, detailed and crypto community reviewed evidence, such as, e.g., AugPAKE (which is another TLS-aimed draft) and others. So, if the TLS WG has considered a feature comparison, that would be good to share. I would recommend to ask CFRG to carefully review the corresponding irtf-dragonfly-02 document (to my knowledge, there has been no LC and it is still a draft document there) and align the TLS document draft-ietf-tls-pwd-02 document with whatever comes out of that effort (currently, there are some security-relevant differences). This time window could also be used for firming up security rationale, thus aleviating concerns on that front. Two final comments: a) It is unclear why one should hard code in the draft that elliptic curves with co-factor h>1 would be ruled out. After all, this would make it much harder to extend the reach of the draft to prime curves with co-factor larger than one and to binary curves. b) The probabilistic nature of the "hunting and pecking" procedure may be a recipe for triggering implementation attacks. Wouldn't one be much better off removing dependency on non-deterministic password-to-point mappings (e.g., AugPAKE, Icart map, German BSI-password protocol)? Best regards, Rene On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote: > This is the beginning of the working group last call for draft-ietf-tls-pwd-01. The underlying cryptographic protocol for TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory results. The document needs particular attention paid to the integration of this mechanism into the TLS protocol. Please send comments to the TLS list by December 2, 2013. > > - Joe > (For the TLS chairs) > _______________________________________________ > 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 watsonbladd@gmail.com Mon Dec 2 08:40:31 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53661A1F4E for ; Mon, 2 Dec 2013 08:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, 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 iZQOfKZsbeXf for ; Mon, 2 Dec 2013 08:40:29 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 672621ACC8A for ; Mon, 2 Dec 2013 08:40:29 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id a1so4494027wgh.3 for ; Mon, 02 Dec 2013 08:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cNLREy0z8qwNeyFj9Mp48ZymRoPPY0puns5Kssf2v7E=; b=bO+g1UY6ML7rosrfV0jHlzX7BZTaIsmr4WzAyzUK/yU119yGEEKNBaHD3Mnb9jbiAo 3hd6W+0au7nOYBSJdb3odkT2spehcHabMYAW1zNLc9emLkZakJH5DvHOn3fmeK63akTV iIOMBToiTmQ6sSIoMHsuuPJqTsoGfLYWGEih2u0qPXFr717TfjDtX0w1YS9v0KtoYEMU 5odr2T0YndWeYUBjk1rdXlbaZBU+4sz1gQ/Y0G58JdhulqyEuaQfI0yJsomQTD6pFkp3 B4Om2JKf10yp9AKtgkjUvs4XlDhYI3Jsmx3oL0eU2vKp3ij259W/OJFLj/QsAl3+qAp5 lxTQ== MIME-Version: 1.0 X-Received: by 10.194.1.139 with SMTP id 11mr36903882wjm.33.1386002426590; Mon, 02 Dec 2013 08:40:26 -0800 (PST) Received: by 10.194.242.131 with HTTP; Mon, 2 Dec 2013 08:40:26 -0800 (PST) In-Reply-To: <529C990D.3020608@gmail.com> References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> Date: Mon, 2 Dec 2013 08:40:26 -0800 Message-ID: From: Watson Ladd To: Rene Struik Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2013 16:40:31 -0000 On Mon, Dec 2, 2013 at 6:28 AM, Rene Struik wrote: > Dear colleagues: > > I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work tha= t > went into this draft, I have to concur with some other commenters (e.g., > Doug Stebila, Bodo Moeller) that it is unclear what makes this protocol > special compared to other contenders, both in terms of performance and > detailed cryptanalysis. One glaring omission is detailed security evidenc= e, > which is currently lacking (cross-referencing some other standards that h= ave > specified the protocol does not by itself imply the protocol is therefore > secure). I am kind of curious what technical advantages the "Dragonfly" > protocol has over protocols that seem to have efficiency, detailed and > crypto community reviewed evidence, such as, e.g., AugPAKE (which is anot= her > TLS-aimed draft) and others. So, if the TLS WG has considered a feature > comparison, that would be good to share. > > I would recommend to ask CFRG to carefully review the corresponding > irtf-dragonfly-02 document (to my knowledge, there has been no LC and it = is > still a draft document there) and align the TLS document > draft-ietf-tls-pwd-02 document with whatever comes out of that effort > (currently, there are some security-relevant differences). This time wind= ow > could also be used for firming up security rationale, thus aleviating > concerns on that front. I do not like the way this standard mixes algorithmic details with instanti= ation details. It makes it hard for me to understand what the protocol actually i= s. I also do not understand why H needs to be a random oracle as opposed to something we have in the standard model. I also do not like the language of "commitment" used. What is sent is not a Pedersen commitment or any other recognizable commitment. It is very malleable in ways that make me question the informal security analysis. > > Two final comments: > a) It is unclear why one should hard code in the draft that elliptic curv= es > with co-factor h>1 would be ruled out. After all, this would make it much > harder to extend the reach of the draft to prime curves with co-factor > larger than one and to binary curves. I think the authors wanted to specify secure curves and haddn't the slightest to do it right. Weierstrau=C3=9F form has big problems: Edwards is much better from an implementation security perspective. Cofactor isn't enough: you also need high embedding degree, big discriminant, or you could just use curves we agree are good instead of reinventing the w= heel. Higher order protocols should be group agnostic.This prevents a major problem when Joux comes up with something new. > b) The probabilistic nature of the "hunting and pecking" procedure may be= a > recipe for triggering implementation attacks. Wouldn't one be much better > off removing dependency on non-deterministic password-to-point mappings > (e.g., AugPAKE, Icart map, German BSI-password protocol)? Well, one could use Elligator to solve this problem. > > Best regards, Rene > > > On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote: >> >> This is the beginning of the working group last call for >> draft-ietf-tls-pwd-01. The underlying cryptographic protocol for TLS-P= WD >> has been reviewed by the IRTF CFRG group with satisfactory results. The >> document needs particular attention paid to the integration of this >> mechanism into the TLS protocol. Please send comments to the TLS list = by >> December 2, 2013. >> >> - Joe >> (For the TLS chairs) >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 jsalowey@cisco.com Mon Dec 2 11:23:55 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4151ADE8A for ; Mon, 2 Dec 2013 11:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 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.001, 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 1HTqwFhLAazr for ; Mon, 2 Dec 2013 11:23:54 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 28CAE1ADBCD for ; Mon, 2 Dec 2013 11:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2284; q=dns/txt; s=iport; t=1386012232; x=1387221832; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=m8WNnmm1V8tQHLaTAoIFV/RtL3b1o1n6ck3HFPLaz+g=; b=ADKB1qJdeeE8oK4/SWcfLIeY5o3bu0Tx7jVv3YzmNSfAqMFdD4FREaA7 gJb14BHxJMyz7e6wZh0lQIZM0BASiXkMdUNOqMEHT679M28ScaqQy1M7e DlU58R9L0t3UP5VTjPbtS0/mWaSdrOdjooLOUFlBCE8KrPzrwW07JkoYb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAI7dnFKtJV2Y/2dsb2JhbABZgwc4U7oMFnSCLDpRATgGQicEiBShI55fF48ngwiBEwOUMYNjkhODKYFqJBw X-IronPort-AV: E=Sophos;i="4.93,812,1378857600"; d="scan'208";a="3727410" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 02 Dec 2013 19:23:51 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB2JNpaJ005310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 2 Dec 2013 19:23:51 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 13:23:51 -0600 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: TLS Charter Revision Thread-Index: AQHO75QH12xj16hlv0SmAgrMfgWOIQ== Date: Mon, 2 Dec 2013 19:23:50 +0000 Message-ID: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.94.42] Content-Type: text/plain; charset="us-ascii" Content-ID: <4C605628926CD941AAB679BAA481DF39@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] TLS Charter Revision X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2013 19:23:55 -0000 Hi Folks, Sean, Eric and I have been put together a revised TLS working group charter= to cover the TLS 1.3 work. Please review the following charter and send = any comments to the TLS list by December 16, 2013. Thanks, Joe [For the Chairs] The TLS (Transport Layer Security) working group was established in 1996 to standardize a 'transport layer' security protocol. The basis for the work was SSL (Secure Socket Layer) v3.0. The TLS working group has completed a series of specifications that describe the TLS protocol v1.0, v1.1, and v1.2 and DTLS (Datagram TLS) v1.2 as well as extensions to the protocols and ciphersuites. The primary purpose of the working group is to develop (D)TLS v1.3. Some of the main design goals are as follows, in no particular order: o Develop a mode that encrypts as much of the handshake as is possible to reduce the amount of observable data to both passive and active attackers. o Develop modes to reduce handshake latency, which primarily support HTTP-based applications, aiming for one roundtrip for a full handshake and one zero roundtrip for repeated handshakes. o Reevaluate record payload protection cryptographic mechanisms and algorithms to address known weaknesses in RC4 and the CBC block cipher modes. o Reevaluate handshake contents, e.g.,: Is time needed in client hello? Should signature in server key exchange cover entire handshake? Are bigger randoms required? Should there be distinct cipher list for each version? A secondary purpose is to maintain previous version of the (D)TLS protocols as well as to specifying the Use of (D)TLS, recommendations for use of (D)TLS, extensions to (D)TLS, and cipher suites. However, changes or additions to older versions of (D)TLS whether via extensions or ciphersuites are discouraged and require significant justification to be taken on as work items. With these objectives in mind, the TLS WG will also place a priority in minimizing gratuitous changes to TLS. Milestone/Dates: 201311 - Out-of-Band Public Key Validation for TLS to IESG 201401 - Secure Password Ciphersuites for TLS to IESG 201404 - TLS ALPN (Application Layer Protocol Negotiation) Extension to IESG 201411 - (D)TLS 1.3 to IESG From rransom.8774@gmail.com Mon Dec 2 11:30:47 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344C21ADBFF for ; Mon, 2 Dec 2013 11:30:47 -0800 (PST) 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 oGQ1yvRvfbSd for ; Mon, 2 Dec 2013 11:30:45 -0800 (PST) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB9B1AC4A7 for ; Mon, 2 Dec 2013 11:30:45 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id k4so4827302qaq.4 for ; Mon, 02 Dec 2013 11:30:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1QYR5gAoCBStUrtxkJpcgyVJD6RrPJRS9a/ChLgYbeg=; b=bMSyDJIpIPPBQJ7+Dblltd9VC5FxOrPaEJPQvVcsRvmQ+3JfPADQjIo3BFwwRGc4wE ZOCq1k19OFNqIX0GZ2wc018DJqmR7x3zdrttWLVW4Mj2BhwMV/RsYaIPOKDYs6WSfSqE FMDiobFvPaQKjQkzoLeMa+ETzTj62CFoZ5IVr6TKSgtaroOjPj+VmqumhD1tWsCe1aMy /rVgsBdL+qCxLFGaI1BlELxi0L8SAxhTmcwXlANPVm5Ot0YujBdGfZ/7Fa9U+jVUSISh biYzsPCO1u26l3wXM7xG+iJXWK32cvolLtXDFN3YstvK2JzPQzw6Hv5twcKAwd/T5AGT 5EPQ== MIME-Version: 1.0 X-Received: by 10.49.18.100 with SMTP id v4mr18338565qed.76.1386012642938; Mon, 02 Dec 2013 11:30:42 -0800 (PST) Received: by 10.229.8.3 with HTTP; Mon, 2 Dec 2013 11:30:42 -0800 (PST) In-Reply-To: References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> Date: Mon, 2 Dec 2013 11:30:42 -0800 Message-ID: From: Robert Ransom To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2013 19:30:47 -0000 On 12/2/13, Watson Ladd wrote: > On Mon, Dec 2, 2013 at 6:28 AM, Rene Struik wrote= : >> Dear colleagues: >> >> I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work th= at >> went into this draft, I have to concur with some other commenters (e.g., >> Doug Stebila, Bodo Moeller) that it is unclear what makes this protocol >> special compared to other contenders, both in terms of performance and >> detailed cryptanalysis. One glaring omission is detailed security >> evidence, >> which is currently lacking (cross-referencing some other standards that >> have >> specified the protocol does not by itself imply the protocol is therefor= e >> secure). I am kind of curious what technical advantages the "Dragonfly" >> protocol has over protocols that seem to have efficiency, detailed and >> crypto community reviewed evidence, such as, e.g., AugPAKE (which is >> another >> TLS-aimed draft) and others. So, if the TLS WG has considered a feature >> comparison, that would be good to share. >> >> I would recommend to ask CFRG to carefully review the corresponding >> irtf-dragonfly-02 document (to my knowledge, there has been no LC and it >> is >> still a draft document there) and align the TLS document >> draft-ietf-tls-pwd-02 document with whatever comes out of that effort >> (currently, there are some security-relevant differences). This time >> window >> could also be used for firming up security rationale, thus aleviating >> concerns on that front. > I do not like the way this standard mixes algorithmic details with > instantiation > details. It makes it hard for me to understand what the protocol actually > is. > I also do not understand why H needs to be a random oracle as opposed to > something we have in the standard model. > > I also do not like the language of "commitment" used. What is sent is > not a Pedersen commitment or any other recognizable commitment. > It is very malleable in ways that make me question the informal security > analysis. I don't see what advantage their =E2=80=98committment=E2=80=99 [sic] provid= es over using standard Diffie-Hellman with a password-derived secret basepoint. All of the protocol's security against offline attacks and impersonation appears to be provided by requiring that both parties' group elements are in the prime-order subgroup. >> b) The probabilistic nature of the "hunting and pecking" procedure may b= e >> a >> recipe for triggering implementation attacks. Wouldn't one be much bette= r >> off removing dependency on non-deterministic password-to-point mappings >> (e.g., AugPAKE, Icart map, German BSI-password protocol)? > Well, one could use Elligator to solve this problem. The Elligator paper (published in August) cites a PAKE paper from 2001 as a possible use for injective maps. The J-PAKE paper (published in 2008) states that there were no good unpatented PAKE protocols available at the time J-PAKE was published, and even the patented protocols were not secure. Is this protocol related to the 2001 protocol, is that protocol patented, and if so, does that patent cover this protocol? Robert Ransom From dkg@fifthhorseman.net Mon Dec 2 11:40:15 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889EB1AD68D for ; Mon, 2 Dec 2013 11:40:15 -0800 (PST) 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 7PyWPUpmvOdu for ; Mon, 2 Dec 2013 11:40:14 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 145E71AD9B8 for ; Mon, 2 Dec 2013 11:40:14 -0800 (PST) Received: from [192.168.23.229] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 14AC8F986 for ; Mon, 2 Dec 2013 14:40:09 -0500 (EST) Message-ID: <529CE219.4020204@fifthhorseman.net> Date: Mon, 02 Dec 2013 14:40:09 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0 MIME-Version: 1.0 To: IETF TLS WG References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> In-Reply-To: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS Charter Revision X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2013 19:40:15 -0000 minor nit-picks: On 12/02/2013 02:23 PM, Joseph Salowey (jsalowey) wrote: > o Develop modes to reduce handshake latency, which primarily > support HTTP-based applications, aiming for one roundtrip > for a full handshake and one zero roundtrip for repeated > handshakes. what does "one zero roundtrip" mean? should "a full handshake" be "the first handshake" and "repeated handshakes" be "subsequent handshakes" ? > A secondary purpose is to maintain previous version of > the (D)TLS protocols as well as to specifying the Use of this should probably be either "as well as specifying" or "as well as to specify", and "Use" shouldn't be capitalized. --dkg From rransom.8774@gmail.com Mon Dec 2 11:43:42 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3574C1AD8D5 for ; Mon, 2 Dec 2013 11:43:42 -0800 (PST) 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 Cpg7LsnAGrlO for ; Mon, 2 Dec 2013 11:43:41 -0800 (PST) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 140061AC4C5 for ; Mon, 2 Dec 2013 11:43:40 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id ii20so4810239qab.2 for ; Mon, 02 Dec 2013 11:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Uyw3aWixGVk+rGnCaSwM5Y/nBLR6ji3OA/lWBky5RAo=; b=kIS5yIVeVOmTz1rqolS1QzScLX6ZM2DOgaLIOzitTaE5KgEqpUKkprsk8jslUAeso9 fLJFXIbFiQkYDct3AQBUhuNUiI8gRY9yUxsj8ZSDPxj52XsfMpYYEO5RPVPraad+1Q9W iuRpiM+F/XF+KBck+MtampnOv8xKFlJTtEi3z6/WTxoJUsgAK2rdCng/tSKHH6lj1i1o fjq1rG8jt12sQTWeEOUYfw7/SE5hWrzl2+/qF7XYkL8/EGF2W6dZZ+QpTWcNscPFQhOk 2BAI1D6/RH+iCcIc5uFv5KqS+jvYsR0/waEoMKvfLMv7LTKduD5jbAz+TGMU6GoWNcpP 2rug== MIME-Version: 1.0 X-Received: by 10.224.47.3 with SMTP id l3mr117742630qaf.25.1386013418624; Mon, 02 Dec 2013 11:43:38 -0800 (PST) Received: by 10.229.8.3 with HTTP; Mon, 2 Dec 2013 11:43:38 -0800 (PST) In-Reply-To: References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> Date: Mon, 2 Dec 2013 11:43:38 -0800 Message-ID: From: Robert Ransom To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2013 19:43:42 -0000 On 12/2/13, Robert Ransom wrote: > The Elligator paper (published in August) cites a PAKE paper from 2001 > as a possible use for injective maps. The J-PAKE paper (published in > 2008) states that there were no good unpatented PAKE protocols > available at the time J-PAKE was published, and even the patented > protocols were not secure. Is this protocol related to the 2001 > protocol, is that protocol patented, and if so, does that patent cover > this protocol? The J-PAKE paper includes a description of =E2=80=98SPEKE=E2=80=99 (accordi= ng to the citations, published in 1996 and patented in U.S. patent 6,226,383). It is essentially DH with a secret base over a modular-multiplication group. The J-PAKE paper also mentions a theoretical attack that could allow an attacker to test multiple passwords in one protocol execution, although that doesn't seem plausible. I guess someone will have to read the patent to find out whether it claims PWD as well. Robert Ransom From mrex@sap.com Mon Dec 2 15:08:05 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C4E1ADF9B for ; Mon, 2 Dec 2013 15:08:05 -0800 (PST) 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 tx7X08LEDCiN for ; Mon, 2 Dec 2013 15:08:03 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id EBB4D1ADF9D for ; Mon, 2 Dec 2013 15:08:02 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rB2N7wf6029006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Dec 2013 00:07:58 +0100 (MET) In-Reply-To: <1385826600.11639.25.camel@aspire.lan> To: Nikos Mavrogiannopoulos Date: Tue, 3 Dec 2013 00:07:58 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131202230758.8B71B1AB1F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug) 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: Mon, 02 Dec 2013 23:08:06 -0000 Nikos Mavrogiannopoulos wrote: > On Fri, 2013-11-29 at 17:23 -0800, Watson Ladd wrote: > > > > Contrary to popular opinion on this list AtE is a standard way of > > > operation with no flaws known unless used with an unauthenticated pad > > > (as in TLS). When SSL 3.0 was designed AtE was believed to be the > > > conservative approach comparing to EtA. > > The passive voice is doing a lot of work here. Bellare and Namparah > > showed that EtA is generically secure, > > AtE isn't. Rogaway sent out an email in 1995 pleading for EtA in TLS. > > "no flaws known"!="proved to be secure" > > Proven to be secure doesn't mean that attacks don't exist. The TLS > padding scheme was proven to be secure prior to be broken; ironically by > the same person who made the proof. Attacks work by playing outside the > requirements of the proof. > > Nevertheless, there is much more recent work on EtA vs AtE, that > actually proves AtE secure (not "generically" as you pose, you just need > a decent cipher). You may check "The order of encryption and > authentication for protecting communications (or: How secure is SSL?)". > There are even newer papers than that, it is just this that came to > mind. Very important observation. Peter's proposal changes AtE to EtA, but does not currently address the predictable IV for SSLv3 & TLSv1.0. As it turns out, EtA will not protect from BEAST, because it is "generically" secure only against decryption oracles. BEAST was exploiting an _encryption_ oracle. :-) -Martin From watsonbladd@gmail.com Mon Dec 2 19:45:27 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA3B1ADFD3 for ; Mon, 2 Dec 2013 19:45:27 -0800 (PST) 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 4GeuNG2JQTeH for ; Mon, 2 Dec 2013 19:45:25 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6571B1AD698 for ; Mon, 2 Dec 2013 19:45:25 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id y10so11094361wgg.0 for ; Mon, 02 Dec 2013 19:45:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZGUfNtTADDoVRjCTViQrr8+FCSPQLaBkH2VH1zgjorI=; b=RJAHJ6GvqJNMc+B7lj19zJmUDi8iEQ7gaAgRpzQcurPt7VkJrYCy5A6f9esMmpb5Od rSdgeHtp4jTwal/VeriTngCwXIqqITPBbhdThrzr/w6cuCqv/If3ySmzgusWK+Gc88EX 2yN/gHcjIuRUQPGhzbTCNTlwLnilTOfvixzvR/fAvLePxMIigCHmT8v/JPn3VMZAoIp4 7A8nxW3hGsjaqfePUmPmCvAD2JnyrKSJlQ5MnkXWI4ZR2VJyFVeZ8TMr1NnVKsoW4WTK 8lx1o2YXgoK6gNPMaZhIp7pphOAtp7Zmdg9HL0h7rGE+hEZ069Y3usF2Fq7Ov48K/FFV cuJA== MIME-Version: 1.0 X-Received: by 10.180.103.233 with SMTP id fz9mr518875wib.20.1386042322521; Mon, 02 Dec 2013 19:45:22 -0800 (PST) Received: by 10.194.242.131 with HTTP; Mon, 2 Dec 2013 19:45:22 -0800 (PST) In-Reply-To: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> Date: Mon, 2 Dec 2013 19:45:22 -0800 Message-ID: From: Watson Ladd To: "Joseph Salowey (jsalowey)" Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [TLS] TLS Charter Revision X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2013 03:45:27 -0000 I strenuously object to the proposed rechartering as it now stands. First, I do not have confidence in this WG and its chair to deliver a secure protocol to the IESG. They did not the previous 3 times, and I do not want to give them a 4th shot without some guarantee of the quality. Secondly, the proposed recharting has made certain technical decisions related to the protocol without due discussion, in particular the list of goals implies that we keep the stupidity of multiple ciphersuites and extensions galore around. Thirdly, the experience of TLS 1.2 teaches us that no matter how compatible a protocol upgrade is, it will not happen, and so one need not keep compatibility. Fourthly, item 3 is not strong enough: AtE needs to die a fiery death and nothing short of killing RC4 will address its shortcomings. I propose the following charter instead. "To create a protocol establishing a secure encrypted and authenticated channel in the standard model between parties A and B, supporting the following authentication methods: -One-way authentication with the PKI -Two-way authentication with the PKI -Two-way authentication with a shared low-entropy secret -One side authenticated with the PKI, and the other with a shared low-entropy secret. Said protocol will function over UDP and TCP with a minimum of handshakes, complexity, and options, and will have a formal security proof." Sincerely, Watson Ladd From wtc@google.com Mon Dec 2 19:58:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1511ADBC7 for ; Mon, 2 Dec 2013 19:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 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.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 GkuroNm4Bzd0 for ; Mon, 2 Dec 2013 19:58:21 -0800 (PST) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EAA491AD986 for ; Mon, 2 Dec 2013 19:58:20 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id w20so9429535vbb.3 for ; Mon, 02 Dec 2013 19:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=j1ZqsEXhJpZkYyX3QF8UU5RXWspnOUiiJzk/zLVTlS0=; b=j7idh4zsQ9PD/jrUuoVPcTcs1UuqIYy2T3LvymEGq1n7yiUekk6WhfW9j5tCWt3ugS vBNImbmXhl1B7fIPDD5uso7HhWLnf9Ng9goOcPkaI4GVAJWlGqz323aqSXQTQ2l8II6W r4iJcCVpKm3xgGJ751wIrvehMVA1F0oneWPZ01koQWnYJghzUzUkUYqEFn5xBLORKnK/ lR8RfbTNIDJR5Q/nK9jRuvuXFAwKML6FPA6JkhubXio2GKBoOsR6XocsaA4X4dNn+vEg V2V2itqawmK0NySzcuycx9X5LWeHBBlpiMaO2s+Gx0c7ss5fSED9pu0fH27RibqycQs/ 1PMQ== 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:content-type; bh=j1ZqsEXhJpZkYyX3QF8UU5RXWspnOUiiJzk/zLVTlS0=; b=EXh/PIX9xp7kOHukHr1AB1lh0KmsnlAa13mggB6VzynQ2JJ/AbHnLALteyTtjtCxWr VWq3J9QPhIhC4jjkSPRpjDSWM9xXAGEPKcnGQqUSJqy/QFpLgfGGdTHg9N0DxgnYjmw6 ZrS7YhA64Cw463uFM7+hcw4L/MAx1dwRiHa/04PVFO84Jz81EAA0Bej3qFedAsR0ckmI P5LVxPxCXeuVPCmEa1C6BbsWo/fmLd1+GIHuLiPTsMnMXR3x798Dsd2P0fyIXlQAD1fL cuDsFEj62UVAWgSSAPbUfKW1zqC+nkc53Ww9Jji8IgIpFHvMQiKCtmioxkUeX6w5gTOy eZjg== X-Gm-Message-State: ALoCoQmsryWr4Zmw9jPsLNyM5UGb0WasFw6j5BVeQyJmRzv9wTkLRZkzcfvgYERSG64BrT5/jEqfdBGi2NAkQcUKiK9TwXpoimc6BYdxyaQTEEbrJB3FnMWS7YW2OgtRR3ctOzsrhe0R6cxTsreKEcbhAPJHIBKJLbtH0zGdYtMnHtceV8uigW4R9qs9gkY/bV0Ryrj4Q8mq MIME-Version: 1.0 X-Received: by 10.220.192.198 with SMTP id dr6mr4817587vcb.19.1386043098143; Mon, 02 Dec 2013 19:58:18 -0800 (PST) Received: by 10.52.167.10 with HTTP; Mon, 2 Dec 2013 19:58:17 -0800 (PST) In-Reply-To: References: <1385826600.11639.25.camel@aspire.lan> Date: Mon, 2 Dec 2013 19:58:17 -0800 Message-ID: From: Wan-Teh Chang To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2013 03:58:22 -0000 I am a programmer working on the NSS crypto libraries. Here are my thoughts on this issue. 1. Since TLS 1.0 is widely deployed, we don't need to fix this issue for SSL 3.0. This will avoid the need to add another SCSV. 2. I prefer a TLS extension that changes how CBC block ciphers work, rather than adding new AEAD ciphers based on CBC-HMAC. (We already have too many cipher suites.) In addition, CBC block ciphers should work in this new way by default in TLS 1.3. An argument for adding new AEAD ciphers based on CBC-HMAC is that it simplifies testing. The extension-based solution essentially forks every TLS version and increases the number of combinations that need to be tested. 3. I took a look at the TLS/SSL implementation in NSS. I believe that the EtA and pad-MAC-Encrypt proposals should require similar amount of change to the NSS source code. Ignoring the details of padding, It boils down to reordering the operations this way: MAC-pad-Encrypt => pad-MAC-Encrypt vs. reordering the operations this way: MAC-pad-Encrypt => pad-Encrypt-MAC So the assertion that pad-MAC-Encrypt requires a smaller patch doesn't seem to be true for NSS. Caveat: it's possible that the arguments passed to the three operations need more adjustments when the operations are reordered in one way. I didn't look into that. 4. The TLS/SSL implementation in NSS performs the padding itself rather than letting the underlying encryption function do the padding. This means the pad-MAC-Encrypt proposal won't make things more difficult for NSS in this aspect. Wan-Teh Chang From dharkins@lounge.org Tue Dec 3 00:27:45 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4B31AE022 for ; Tue, 3 Dec 2013 00:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 1nfV89ueQH25 for ; Tue, 3 Dec 2013 00:27:43 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 53BE81ADFFF for ; Tue, 3 Dec 2013 00:27:43 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4A2B210224008; Tue, 3 Dec 2013 00:27:40 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 3 Dec 2013 00:27:40 -0800 (PST) Message-ID: <6b51bc68470b316cf6d38c7033c0d451.squirrel@www.trepanning.net> In-Reply-To: <529C990D.3020608@gmail.com> References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> Date: Tue, 3 Dec 2013 00:27:40 -0800 (PST) From: "Dan Harkins" To: "Rene Struik" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tls@ietf.org Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2013 08:27:45 -0000 Dear Rene, On Mon, December 2, 2013 6:28 am, Rene Struik wrote: > Dear colleagues: > > I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work > that went into this draft, I have to concur with some other commenters > (e.g., Doug Stebila, Bodo Moeller) that it is unclear what makes this > protocol special compared to other contenders, both in terms of > performance and detailed cryptanalysis. One glaring omission is detailed > security evidence, which is currently lacking (cross-referencing some > other standards that have specified the protocol does not by itself > imply the protocol is therefore secure). I am kind of curious what > technical advantages the "Dragonfly" protocol has over protocols that > seem to have efficiency, detailed and crypto community reviewed > evidence, such as, e.g., AugPAKE (which is another TLS-aimed draft) and > others. So, if the TLS WG has considered a feature comparison, that > would be good to share. dragonfly is a balanced PAKE kind of exchange and it has certain advantages over augmented PAKE schemes like TLS-SRP (which, unlike the augPAKE draft, is a published RFC that has been implemented). Namely, the domain parameter set is not fixed with the password and can be negotiated to provide security commensurate with that offered by the rest of the cipher suite. And yes, the drawback of a balanced PAKE scheme is that if the server is compromised and the password file exposed then an attacker can impersonate users (although, in my opinion, that is something of a dubious benefit since the server is already compromised and this will be the least of your problems). This has already been discussed in this thread by the way. > I would recommend to ask CFRG to carefully review the corresponding > irtf-dragonfly-02 document (to my knowledge, there has been no LC and it > is still a draft document there) and align the TLS document > draft-ietf-tls-pwd-02 document with whatever comes out of that effort > (currently, there are some security-relevant differences). This time > window could also be used for firming up security rationale, thus > aleviating concerns on that front. This suggestion has already been done. > Two final comments: > a) It is unclear why one should hard code in the draft that elliptic > curves with co-factor h>1 would be ruled out. After all, this would make > it much harder to extend the reach of the draft to prime curves with > co-factor larger than one and to binary curves. You're right, it does prevent the use of binary curves and prime curves with a co-factor greater than one. That's the whole point. The motivation is to avoid walking through a patent mine field. > b) The probabilistic nature of the "hunting and pecking" procedure may > be a recipe for triggering implementation attacks. Wouldn't one be much > better off removing dependency on non-deterministic password-to-point > mappings (e.g., AugPAKE, Icart map, German BSI-password protocol)? The "hunting and pecking" procedure is deterministic otherwise there would be no guarantee that each side arrived at the same element given the same input. regards, Dan. > Best regards, Rene > > On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote: >> This is the beginning of the working group last call for >> draft-ietf-tls-pwd-01. The underlying cryptographic protocol for >> TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory >> results. The document needs particular attention paid to the >> integration of this mechanism into the TLS protocol. Please send >> comments to the TLS list by December 2, 2013. >> >> - Joe >> (For the TLS chairs) >> _______________________________________________ >> 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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From dharkins@lounge.org Tue Dec 3 00:50:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22B91AE0D2 for ; Tue, 3 Dec 2013 00:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 263aP5rkU1DC for ; Tue, 3 Dec 2013 00:50:43 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 43D8D1AE0D1 for ; Tue, 3 Dec 2013 00:50:43 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 093ED10224008; Tue, 3 Dec 2013 00:50:40 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 3 Dec 2013 00:50:40 -0800 (PST) Message-ID: In-Reply-To: References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> Date: Tue, 3 Dec 2013 00:50:40 -0800 (PST) From: "Dan Harkins" To: "Watson Ladd" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tls@ietf.org Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2013 08:50:44 -0000 On Mon, December 2, 2013 8:40 am, Watson Ladd wrote: > On Mon, Dec 2, 2013 at 6:28 AM, Rene Struik wrote: >> Dear colleagues: >> >> I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work >> that >> went into this draft, I have to concur with some other commenters (e.g., >> Doug Stebila, Bodo Moeller) that it is unclear what makes this protocol >> special compared to other contenders, both in terms of performance and >> detailed cryptanalysis. One glaring omission is detailed security >> evidence, >> which is currently lacking (cross-referencing some other standards that >> have >> specified the protocol does not by itself imply the protocol is >> therefore >> secure). I am kind of curious what technical advantages the "Dragonfly" >> protocol has over protocols that seem to have efficiency, detailed and >> crypto community reviewed evidence, such as, e.g., AugPAKE (which is >> another >> TLS-aimed draft) and others. So, if the TLS WG has considered a feature >> comparison, that would be good to share. >> >> I would recommend to ask CFRG to carefully review the corresponding >> irtf-dragonfly-02 document (to my knowledge, there has been no LC and it >> is >> still a draft document there) and align the TLS document >> draft-ietf-tls-pwd-02 document with whatever comes out of that effort >> (currently, there are some security-relevant differences). This time >> window >> could also be used for firming up security rationale, thus aleviating >> concerns on that front. > I do not like the way this standard mixes algorithmic details with > instantiation > details. It makes it hard for me to understand what the protocol actually > is. > I also do not understand why H needs to be a random oracle as opposed to > something we have in the standard model. It is difficult to understand how to act on this comment. The specification is of a cipher suite added to an existing protocol and as such has to "mix" the details of the underlying key exchange with the structure and format of the protocol it is being added to. It is not a high-level description of the algorithm, it is a description of how to implement the key exchange as a TLS cipher suit. > I also do not like the language of "commitment" used. What is sent is > not a Pedersen commitment or any other recognizable commitment. > It is very malleable in ways that make me question the informal security > analysis. Of course it's a recognizable commitment because it allows the sender to commit to a particular value (the password) without exposing it to anyone else. >> Two final comments: >> a) It is unclear why one should hard code in the draft that elliptic >> curves >> with co-factor h>1 would be ruled out. After all, this would make it >> much >> harder to extend the reach of the draft to prime curves with co-factor >> larger than one and to binary curves. > I think the authors wanted to specify secure curves and haddn't the > slightest to do it right. (Note: I always like to have my intelligence questioned with a statement that has multiple grammatical errors). As I mentioned to Rene, the reason for limiting the curves to those over a prime field with a co-factor of 1 is to avoid the patent mine field. > Weierstrauß form has big problems: Edwards is much better from an > implementation security > perspective. Cofactor isn't enough: you also need high embedding > degree, big discriminant, > or you could just use curves we agree are good instead of reinventing the > wheel. > > Higher order protocols should be group agnostic.This prevents a major > problem when > Joux comes up with something new. It specifies a single group for interoperability purposes. It's "crypto agility" is inherited from TLS. Dan. >> b) The probabilistic nature of the "hunting and pecking" procedure may >> be a >> recipe for triggering implementation attacks. Wouldn't one be much >> better >> off removing dependency on non-deterministic password-to-point mappings >> (e.g., AugPAKE, Icart map, German BSI-password protocol)? > Well, one could use Elligator to solve this problem. >> >> Best regards, Rene >> >> >> On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote: >>> >>> This is the beginning of the working group last call for >>> draft-ietf-tls-pwd-01. The underlying cryptographic protocol for >>> TLS-PWD >>> has been reviewed by the IRTF CFRG group with satisfactory results. >>> The >>> document needs particular attention paid to the integration of this >>> mechanism into the TLS protocol. Please send comments to the TLS list >>> by >>> December 2, 2013. >>> >>> - Joe >>> (For the TLS chairs) >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From codesinchaos@gmail.com Tue Dec 3 04:19:23 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2FF1AE11E for ; Tue, 3 Dec 2013 04:19:23 -0800 (PST) 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 vl195acJLW0V for ; Tue, 3 Dec 2013 04:19:22 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id BAF261AE118 for ; Tue, 3 Dec 2013 04:19:21 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id n12so12357858wgh.33 for ; Tue, 03 Dec 2013 04:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JE/jsSX9GvNMwtAnTK0NZesY6/4Kf/drXhm373VJ8Io=; b=DcmtxG1Qk6ZYjcp5b/ssJEVCYrxc/dN4cQVrZfb3B7VX/v2zIorZ1iMUIBKz4BjdpQ InDidp7WSyInjqoeg2ce67c61r/xaQkmj0weHcBX35LCKJ67rtW3AnoH+Tu2pdvvkFbE QZ2QgeQsvbKn1Sa8DF4qisvRVIgy9LwaShJ2idO770CqknRkspCuF+VsdtZOpP/dzXDr atKXzrp+zaO4A3+/FJM1oj/exjT0JL7zQiBEzUavbG53GGjqs2kM2CYCO54mJLmwJ1tf d6Y0wFCTZbMaDbZWIl3DyKHwmva72mIV9Sy9qmQv1x6nBoTZurv42WEF9FabBinD8VKy ZJsg== MIME-Version: 1.0 X-Received: by 10.194.250.100 with SMTP id zb4mr6937286wjc.62.1386073158704; Tue, 03 Dec 2013 04:19:18 -0800 (PST) Received: by 10.216.61.15 with HTTP; Tue, 3 Dec 2013 04:19:18 -0800 (PST) In-Reply-To: <6b51bc68470b316cf6d38c7033c0d451.squirrel@www.trepanning.net> References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> <6b51bc68470b316cf6d38c7033c0d451.squirrel@www.trepanning.net> Date: Tue, 3 Dec 2013 13:19:18 +0100 Message-ID: From: CodesInChaos To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2013 12:19:23 -0000 The protocol uses a fast hash to hash the password. The challenge-response nature of the protocol means that the sever cannot apply additional hashing. This implies that the server needs to store a badly hashed password which is easy to crack when the database is compromised. While the information on the wire doesn't enable an offline dictionary attack, database leaks are common. So being strong against those attacks is important. Why did you use a fast hash like HMAC-SHA-256 over a proper password hash like PBKDF2-HMAC-SHA-256? Why does the security considerations section not mention password guessing attacks / offline dictionary attacks against a compromised database? From rstruik.ext@gmail.com Tue Dec 3 06:16:00 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF221AD694 for ; Tue, 3 Dec 2013 06:16:00 -0800 (PST) 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 IVuss9iujrUF for ; Tue, 3 Dec 2013 06:15:56 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id BB1911AD7C0 for ; Tue, 3 Dec 2013 06:15:56 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so22908627ieb.8 for ; Tue, 03 Dec 2013 06:15:54 -0800 (PST) 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; bh=9TtMsowcxJqM0wDLbPzIOAPiTU5PMMe/c93OOpw5XDw=; b=I+eGqaK2kWytJ5mBOeR+OnoyEX5QMFw0kjQmG/dubTKbgN/Mlfi5tyEsVUwrgRJZgC lzvYqglTOesCOfoMzMyUmKbGP6arrP9zPF80vq4rv51TnIIlQZtx88ax26QZT+pbcdR+ QebQzEGJnKtFmYXgqLZZ9aWI3Yju6qsdWfiIsylaE+E2H/VzduCaSCz+DEbJqsLOeHQW 6JO4MpqtgnhBX64BSQRpBRxP3Ddog7LroY86Z3KCWzsFp10piyN68fg4Bx7moWXl++hR 4oOlGBadN6aNprivXShwMSQlCKrO7T40zS7Oq7rQc/RVNq3HN9rzInGiqmufMFpTD8Rs 0pPQ== X-Received: by 10.50.109.132 with SMTP id hs4mr2827126igb.34.1386080154150; Tue, 03 Dec 2013 06:15:54 -0800 (PST) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.230.254.17]) by mx.google.com with ESMTPSA id v9sm3247089igh.7.2013.12.03.06.15.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 06:15:53 -0800 (PST) Message-ID: <529DE795.5060203@gmail.com> Date: Tue, 03 Dec 2013 09:15:49 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Dan Harkins References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> <6b51bc68470b316cf6d38c7033c0d451.squirrel@www.trepanning.net> In-Reply-To: <6b51bc68470b316cf6d38c7033c0d451.squirrel@www.trepanning.net> Content-Type: multipart/alternative; boundary="------------010906090002050602030700" Cc: tls@ietf.org Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2013 14:16:00 -0000 This is a multi-part message in MIME format. --------------010906090002050602030700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dan: I could not find that CFRG had a LC on this. In case I missed this, please kindly provide a pointer. Triggered by the TLS WG LC, I decided the review the Dragonfly protocol document last Friday (since TLS WG LC suggested CFRG had "blessed" this) and sent my review to the CFRG email reflector. One can find this review here:http://permalink.gmane.org/gmane.ietf.irtf.cfrg/2127 . I suggest you have a discussion on how to fix security comments raised on the CFRG dragonfly protocol on that list. As far as I am concerned, my TLS WGLC comments still stand. Best regards, Rene On 12/3/2013 3:27 AM, Dan Harkins wrote: > Dear Rene, > > On Mon, December 2, 2013 6:28 am, Rene Struik wrote: >> Dear colleagues: >> >> I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work >> that went into this draft, I have to concur with some other commenters >> (e.g., Doug Stebila, Bodo Moeller) that it is unclear what makes this >> protocol special compared to other contenders, both in terms of >> performance and detailed cryptanalysis. One glaring omission is detailed >> security evidence, which is currently lacking (cross-referencing some >> other standards that have specified the protocol does not by itself >> imply the protocol is therefore secure). I am kind of curious what >> technical advantages the "Dragonfly" protocol has over protocols that >> seem to have efficiency, detailed and crypto community reviewed >> evidence, such as, e.g., AugPAKE (which is another TLS-aimed draft) and >> others. So, if the TLS WG has considered a feature comparison, that >> would be good to share. > dragonfly is a balanced PAKE kind of exchange and it has certain > advantages over augmented PAKE schemes like TLS-SRP (which, unlike > the augPAKE draft, is a published RFC that has been implemented). > Namely, the domain parameter set is not fixed with the password and > can be negotiated to provide security commensurate with that offered > by the rest of the cipher suite. And yes, the drawback of a balanced > PAKE scheme is that if the server is compromised and the password > file exposed then an attacker can impersonate users (although, in my > opinion, that is something of a dubious benefit since the server is > already compromised and this will be the least of your problems). > > This has already been discussed in this thread by the way. > >> I would recommend to ask CFRG to carefully review the corresponding >> irtf-dragonfly-02 document (to my knowledge, there has been no LC and it >> is still a draft document there) and align the TLS document >> draft-ietf-tls-pwd-02 document with whatever comes out of that effort >> (currently, there are some security-relevant differences). This time >> window could also be used for firming up security rationale, thus >> aleviating concerns on that front. > This suggestion has already been done. > >> Two final comments: >> a) It is unclear why one should hard code in the draft that elliptic >> curves with co-factor h>1 would be ruled out. After all, this would make >> it much harder to extend the reach of the draft to prime curves with >> co-factor larger than one and to binary curves. > You're right, it does prevent the use of binary curves and prime curves > with a co-factor greater than one. That's the whole point. The motivation > is to avoid walking through a patent mine field. > >> b) The probabilistic nature of the "hunting and pecking" procedure may >> be a recipe for triggering implementation attacks. Wouldn't one be much >> better off removing dependency on non-deterministic password-to-point >> mappings (e.g., AugPAKE, Icart map, German BSI-password protocol)? > The "hunting and pecking" procedure is deterministic otherwise there > would be no guarantee that each side arrived at the same element > given the same input. > > regards, > > Dan. > >> Best regards, Rene >> >> On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote: >>> This is the beginning of the working group last call for >>> draft-ietf-tls-pwd-01. The underlying cryptographic protocol for >>> TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory >>> results. The document needs particular attention paid to the >>> integration of this mechanism into the TLS protocol. Please send >>> comments to the TLS list by December 2, 2013. >>> >>> - Joe >>> (For the TLS chairs) >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 --------------010906090002050602030700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Dan:

I could not find that CFRG had a LC on this. In case I missed this, please kindly provide a pointer.

Triggered by the TLS WG LC, I decided the review the Dragonfly protocol document last Friday (since TLS WG LC suggested CFRG had "blessed" this) and sent my review to the CFRG email reflector. One can find this review here: http://permalink.gmane.org/gmane.ietf.irtf.cfrg/2127.

I suggest you have a discussion on how to fix security comments raised on the CFRG dragonfly protocol on that list.

As far as I am concerned, my TLS WGLC comments still stand.

Best regards, Rene

On 12/3/2013 3:27 AM, Dan Harkins wrote:
  Dear Rene,

On Mon, December 2, 2013 6:28 am, Rene Struik wrote:

Dear colleagues:

I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work
that went into this draft, I have to concur with some other commenters
(e.g., Doug Stebila, Bodo Moeller) that it is unclear what makes this
protocol special compared to other contenders, both in terms of
performance and detailed cryptanalysis. One glaring omission is detailed
security evidence, which is currently lacking (cross-referencing some
other standards that have specified the protocol does not by itself
imply the protocol is therefore secure). I am kind of curious what
technical advantages the "Dragonfly" protocol has over protocols that
seem to have efficiency, detailed and crypto community reviewed
evidence, such as, e.g., AugPAKE (which is another TLS-aimed draft) and
others. So, if the TLS WG has considered a feature comparison, that
would be good to share.

  dragonfly is a balanced PAKE kind of exchange and it has certain
advantages over augmented PAKE schemes like TLS-SRP (which, unlike
the augPAKE draft, is a published RFC that has been implemented).
Namely, the domain parameter set is not fixed with the password and
can be negotiated to provide security commensurate with that offered
by the rest of the cipher suite. And yes, the drawback of a balanced
PAKE scheme is that if the server is compromised and the password
file exposed then an attacker can impersonate users (although, in my
opinion, that is something of a dubious benefit since the server is
already compromised and this will be the least of your problems).

  This has already been discussed in this thread by the way.


I would recommend to ask CFRG to carefully review the corresponding
irtf-dragonfly-02 document (to my knowledge, there has been no LC and it
is still a draft document there) and align the TLS document
draft-ietf-tls-pwd-02 document with whatever comes out of that effort
(currently, there are some security-relevant differences). This time
window could also be used for firming up security rationale, thus
aleviating concerns on that front.

  This suggestion has already been done.


Two final comments:
a) It is unclear why one should hard code in the draft that elliptic
curves with co-factor h>1 would be ruled out. After all, this would make
it much harder to extend the reach of the draft to prime curves with
co-factor larger than one and to binary curves.

  You're right, it does prevent the use of binary curves and prime curves
with a co-factor greater than one. That's the whole point. The motivation
is to avoid walking through a patent mine field.


b) The probabilistic nature of the "hunting and pecking" procedure may
be a recipe for triggering implementation attacks. Wouldn't one be much
better off removing dependency on non-deterministic password-to-point
mappings (e.g., AugPAKE, Icart map, German BSI-password protocol)?

  The "hunting and pecking" procedure is deterministic otherwise there
would be no guarantee that each side arrived at the same element
given the same input.

  regards,

  Dan.


Best regards, Rene

On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote:

This is the beginning of the working group last call for
draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory
results.  The document needs particular attention paid to the
integration of this mechanism into the TLS protocol.   Please send
comments to the TLS list by December 2, 2013.

- Joe
(For the TLS chairs)
_______________________________________________
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

_______________________________________________
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

  


--------------010906090002050602030700--

From watsonbladd@gmail.com  Tue Dec  3 08:12:33 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1745D1A1F66 for ; Tue,  3 Dec 2013 08:12:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, 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 8Ws2wiH8AfPS for ; Tue,  3 Dec 2013 08:12:31 -0800 (PST)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C10661A1F19 for ; Tue,  3 Dec 2013 08:12:30 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id u57so8037181wes.4 for ; Tue, 03 Dec 2013 08:12:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=ADn+W9v/RNQ8lQegi01Vzm3aE75Jirpz8NMX+8TBuOY=; b=frBSGZf486xY5mGZMgLc4v7Y6jKV2rpjxFd1id7QWmXb6vjIqjeq4F4eWJEV0g20R9 8xENV32CrMgeiVZaFKlJOpckVMoFuG9b18XZ0ZG5HLcHx8P5WNMToGKME+AQN2c2CZyV gHx2LWjWAku83szaBFKxCw0Mk+6346AdPy7QzHaVGp5p9drgo98z6ouELXPreV7He7RI p8AIszPz3iRRDOOsYk+FD5Cu/0J1ftQ0x+aux4IFWgmapLaEFt78EV/s8ZRlZ+Bo5lG1 oR2dNNy0zKXk0BBdyoSDtLGi3kHohLtPf08ztUK2yaRjl6DCS2YWmwCv6yuP/Hr5wn3R iHag==
MIME-Version: 1.0
X-Received: by 10.194.48.115 with SMTP id k19mr7905177wjn.47.1386087147652; Tue, 03 Dec 2013 08:12:27 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Tue, 3 Dec 2013 08:12:27 -0800 (PST)
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>  
Date: Tue, 3 Dec 2013 08:12:27 -0800
Message-ID: 
From: Watson Ladd 
To: Dan Harkins , "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 03 Dec 2013 16:12:33 -0000

On Tue, Dec 3, 2013 at 12:50 AM, Dan Harkins  wrote:
>
> On Mon, December 2, 2013 8:40 am, Watson Ladd wrote:
>> On Mon, Dec 2, 2013 at 6:28 AM, Rene Struik  wrot=
e:
>>> Dear colleagues:
>>>
>>> I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work
>>> that
>>> went into this draft, I have to concur with some other commenters (e.g.=
,
>>> Doug Stebila, Bodo Moeller) that it is unclear what makes this protocol
>>> special compared to other contenders, both in terms of performance and
>>> detailed cryptanalysis. One glaring omission is detailed security
>>> evidence,
>>> which is currently lacking (cross-referencing some other standards that
>>> have
>>> specified the protocol does not by itself imply the protocol is
>>> therefore
>>> secure). I am kind of curious what technical advantages the "Dragonfly"
>>> protocol has over protocols that seem to have efficiency, detailed and
>>> crypto community reviewed evidence, such as, e.g., AugPAKE (which is
>>> another
>>> TLS-aimed draft) and others. So, if the TLS WG has considered a feature
>>> comparison, that would be good to share.
>>>
>>> I would recommend to ask CFRG to carefully review the corresponding
>>> irtf-dragonfly-02 document (to my knowledge, there has been no LC and i=
t
>>> is
>>> still a draft document there) and align the TLS document
>>> draft-ietf-tls-pwd-02 document with whatever comes out of that effort
>>> (currently, there are some security-relevant differences). This time
>>> window
>>> could also be used for firming up security rationale, thus aleviating
>>> concerns on that front.
>> I do not like the way this standard mixes algorithmic details with
>> instantiation
>> details. It makes it hard for me to understand what the protocol actuall=
y
>> is.
>> I also do not understand why H needs to be a random oracle as opposed to
>> something we have in the standard model.
>
>   It is difficult to understand how to act on this comment. The specifica=
tion
> is of a cipher suite added to an existing protocol and as such has to
> "mix" the
> details of the underlying key exchange with the structure and format of t=
he
> protocol it is being added to. It is not a high-level description of the
> algorithm,
> it is a description of how to implement the key exchange as a TLS cipher
> suit.
What protocol is this standard implementing? Where is it documented? Where =
is
the security proof?
>
>> I also do not like the language of "commitment" used. What is sent is
>> not a Pedersen commitment or any other recognizable commitment.
>> It is very malleable in ways that make me question the informal security
>> analysis.
>
>   Of course it's a recognizable commitment because it allows the sender
> to commit to a particular value (the password) without exposing it to
> anyone else.
The sender is committed to the password, but not to the value of the PE poi=
nt.
This is noted in the "security analysis" section, but absent a proof I
can't tell you
that it doesn't matter. The security analysis section reads like a
bunch of attacks
were tried and failed. All that shows is *you* couldn't break it, not
that anyone else
couldn't.
>
>>> Two final comments:
>>> a) It is unclear why one should hard code in the draft that elliptic
>>> curves
>>> with co-factor h>1 would be ruled out. After all, this would make it
>>> much
>>> harder to extend the reach of the draft to prime curves with co-factor
>>> larger than one and to binary curves.
>> I think the authors wanted to specify secure curves and haddn't the
>> slightest to do it right.
>
>   (Note: I always like to have my intelligence questioned with a statemen=
t
> that has multiple grammatical errors).
It's not your intell
>
>   As I mentioned to Rene, the reason for limiting the curves to those
> over a prime field with a co-factor of 1 is to avoid the patent mine fiel=
d.
What mine field? What is so patented about cofactor>1 over prime field?
For binary curves I agree. But why not use whatever curve TLS specifies?
Also, why not use the existing mechanisms to deal with implementation limit=
s
caused by patents?
>
>> Weierstrau=C3=9F form has big problems: Edwards is much better from an
>> implementation security
>> perspective. Cofactor isn't enough: you also need high embedding
>> degree, big discriminant,
>> or you could just use curves we agree are good instead of reinventing th=
e
>> wheel.
>>
>> Higher order protocols should be group agnostic.This prevents a major
>> problem when
>> Joux comes up with something new.
>
>   It specifies a single group for interoperability purposes. It's "crypto
> agility" is inherited from TLS.
>
>   Dan.
>
>>> b) The probabilistic nature of the "hunting and pecking" procedure may
>>> be a
>>> recipe for triggering implementation attacks. Wouldn't one be much
>>> better
>>> off removing dependency on non-deterministic password-to-point mappings
>>> (e.g., AugPAKE, Icart map, German BSI-password protocol)?
>> Well, one could use Elligator to solve this problem.
>>>
>>> Best regards, Rene
>>>
>>>
>>> On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote:
>>>>
>>>> This is the beginning of the working group last call for
>>>> draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
>>>> TLS-PWD
>>>> has been reviewed by the IRTF CFRG group with satisfactory results.
>>>> The
>>>> document needs particular attention paid to the integration of this
>>>> mechanism into the TLS protocol.   Please send comments to the TLS lis=
t
>>>> by
>>>> December 2, 2013.
>>>>
>>>> - Joe
>>>> (For the TLS chairs)
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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 dharkins@lounge.org  Tue Dec  3 09:41:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091DD1AC82A for ; Tue,  3 Dec 2013 09:41:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 aOT4gzxdL-YP for ; Tue,  3 Dec 2013 09:41:32 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2001ABD2A for ; Tue,  3 Dec 2013 09:41:32 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C886210224008; Tue,  3 Dec 2013 09:41:29 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 3 Dec 2013 09:41:30 -0800 (PST)
Message-ID: <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>   
Date: Tue, 3 Dec 2013 09:41:30 -0800 (PST)
From: "Dan Harkins" 
To: "Watson Ladd" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 03 Dec 2013 17:41:35 -0000

On Tue, December 3, 2013 8:12 am, Watson Ladd wrote:
> On Tue, Dec 3, 2013 at 12:50 AM, Dan Harkins  wrote:
>>
>> On Mon, December 2, 2013 8:40 am, Watson Ladd wrote:
>>> On Mon, Dec 2, 2013 at 6:28 AM, Rene Struik 
>>> wrote:
>>>> Dear colleagues:
>>>>
>>>> I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work
>>>> that
>>>> went into this draft, I have to concur with some other commenters
>>>> (e.g.,
>>>> Doug Stebila, Bodo Moeller) that it is unclear what makes this
>>>> protocol
>>>> special compared to other contenders, both in terms of performance and
>>>> detailed cryptanalysis. One glaring omission is detailed security
>>>> evidence,
>>>> which is currently lacking (cross-referencing some other standards
>>>> that
>>>> have
>>>> specified the protocol does not by itself imply the protocol is
>>>> therefore
>>>> secure). I am kind of curious what technical advantages the
>>>> "Dragonfly"
>>>> protocol has over protocols that seem to have efficiency, detailed and
>>>> crypto community reviewed evidence, such as, e.g., AugPAKE (which is
>>>> another
>>>> TLS-aimed draft) and others. So, if the TLS WG has considered a
>>>> feature
>>>> comparison, that would be good to share.
>>>>
>>>> I would recommend to ask CFRG to carefully review the corresponding
>>>> irtf-dragonfly-02 document (to my knowledge, there has been no LC and
>>>> it
>>>> is
>>>> still a draft document there) and align the TLS document
>>>> draft-ietf-tls-pwd-02 document with whatever comes out of that effort
>>>> (currently, there are some security-relevant differences). This time
>>>> window
>>>> could also be used for firming up security rationale, thus aleviating
>>>> concerns on that front.
>>> I do not like the way this standard mixes algorithmic details with
>>> instantiation
>>> details. It makes it hard for me to understand what the protocol
>>> actually
>>> is.
>>> I also do not understand why H needs to be a random oracle as opposed
>>> to
>>> something we have in the standard model.
>>
>>   It is difficult to understand how to act on this comment. The
>> specification
>> is of a cipher suite added to an existing protocol and as such has to
>> "mix" the
>> details of the underlying key exchange with the structure and format of
>> the
>> protocol it is being added to. It is not a high-level description of the
>> algorithm,
>> it is a description of how to implement the key exchange as a TLS cipher
>> suit.
> What protocol is this standard implementing? Where is it documented? Where
> is
> the security proof?

  Do you have a specific comment on the draft itself? "I don't like it" is an
unactionable editorial comment.

>>> I also do not like the language of "commitment" used. What is sent is
>>> not a Pedersen commitment or any other recognizable commitment.
>>> It is very malleable in ways that make me question the informal
>>> security
>>> analysis.
>>
>>   Of course it's a recognizable commitment because it allows the sender
>> to commit to a particular value (the password) without exposing it to
>> anyone else.
> The sender is committed to the password, but not to the value of the PE
> point.

  There is a one-to-one mapping of password (plus username and salt)
and point. If one is committed to the password, he's committed to the
point.

> This is noted in the "security analysis" section, but absent a proof I
> can't tell you
> that it doesn't matter. The security analysis section reads like a
> bunch of attacks
> were tried and failed. All that shows is *you* couldn't break it, not
> that anyone else
> couldn't.
>>
>>>> Two final comments:
>>>> a) It is unclear why one should hard code in the draft that elliptic
>>>> curves
>>>> with co-factor h>1 would be ruled out. After all, this would make it
>>>> much
>>>> harder to extend the reach of the draft to prime curves with co-factor
>>>> larger than one and to binary curves.
>>> I think the authors wanted to specify secure curves and haddn't the
>>> slightest to do it right.
>>
>>   (Note: I always like to have my intelligence questioned with a
>> statement
>> that has multiple grammatical errors).
> It's not your intell

  Again, thank you for that comment.

>>   As I mentioned to Rene, the reason for limiting the curves to those
>> over a prime field with a co-factor of 1 is to avoid the patent mine
>> field.
> What mine field? What is so patented about cofactor>1 over prime field?
> For binary curves I agree.

  There are plenty of patents that deal with acceleration when the
cofactor is > 1 or deal with verification of received elements when
the cofactor is > 1. I just don't want to deal with it.

>                                         But why not use whatever curve
TLS specifies?
> Also, why not use the existing mechanisms to deal with implementation
> limits
> caused by patents?

  What mechanisms _speciifcally_ is TLS-pwd doing that is causing you
to say this? It uses the existing mechanisms provided by the base TLS
protocol to convey the group to use. Again, I don't know how to address
a comment that says to change the protocol to do what it already does.

>>> Weierstrauß form has big problems: Edwards is much better from an
>>> implementation security
>>> perspective. Cofactor isn't enough: you also need high embedding
>>> degree, big discriminant,
>>> or you could just use curves we agree are good instead of reinventing
>>> the
>>> wheel.

  "[U]se curves we all agree are good instead of reinventing the wheel"? Now
I'm starting to think you didn't even read the draft.

  Dan.

>>> Higher order protocols should be group agnostic.This prevents a major
>>> problem when
>>> Joux comes up with something new.
>>
>>   It specifies a single group for interoperability purposes. It's
>> "crypto
>> agility" is inherited from TLS.
>>
>>   Dan.
>>
>>>> b) The probabilistic nature of the "hunting and pecking" procedure may
>>>> be a
>>>> recipe for triggering implementation attacks. Wouldn't one be much
>>>> better
>>>> off removing dependency on non-deterministic password-to-point
>>>> mappings
>>>> (e.g., AugPAKE, Icart map, German BSI-password protocol)?
>>> Well, one could use Elligator to solve this problem.
>>>>
>>>> Best regards, Rene
>>>>
>>>>
>>>> On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote:
>>>>>
>>>>> This is the beginning of the working group last call for
>>>>> draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
>>>>> TLS-PWD
>>>>> has been reviewed by the IRTF CFRG group with satisfactory results.
>>>>> The
>>>>> document needs particular attention paid to the integration of this
>>>>> mechanism into the TLS protocol.   Please send comments to the TLS
>>>>> list
>>>>> by
>>>>> December 2, 2013.
>>>>>
>>>>> - Joe
>>>>> (For the TLS chairs)
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>> _______________________________________________
>>> 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 watsonbladd@gmail.com  Tue Dec  3 10:08:53 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B231AD943 for ; Tue,  3 Dec 2013 10:08:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, 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 kuYAI0D5KdUT for ; Tue,  3 Dec 2013 10:08:50 -0800 (PST)
Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD3C1AD6D2 for ; Tue,  3 Dec 2013 10:08:50 -0800 (PST)
Received: by mail-wg0-f54.google.com with SMTP id n12so12621923wgh.21 for ; Tue, 03 Dec 2013 10:08:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=K42ToFJsc81RY/dVkCNdjgyHehvrmtOwNkodBYWmIc4=; b=OFnuI7ocBhrAtEpR/VhPTuXuOJ9gNDr4mj7XGOF3df41Qk9R9RW3FdSRjNMddb+CON B/kszSvsLRwkRwwrSuC82x93E7beK7jESnxtFFyzpWnPYGzmCXDk0kLip2IWl4i5Sikt 0xtEBKtOaWHeHcgHXXfaQq2e7Q0jMjl0H+8LV/y82J8EVgaoL/Km5DUG+b2V6NsrtFVD oN0swRegIqZrb7xRWhcJBbg4JDBfIQpGEZcKLeQl5Nsx/bhoRA96//iX2kNRHXiFNbup xOTsccjyl2/q1f7ycDAkVmlt75sDgf6cveQa5ArwWa16abiYo69CfAhhgQEUTt8bJ3Uj xbiQ==
MIME-Version: 1.0
X-Received: by 10.194.250.100 with SMTP id zb4mr8527561wjc.62.1386094127144; Tue, 03 Dec 2013 10:08:47 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Tue, 3 Dec 2013 10:08:47 -0800 (PST)
In-Reply-To: <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>
Date: Tue, 3 Dec 2013 10:08:47 -0800
Message-ID: 
From: Watson Ladd 
To: Dan Harkins 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 03 Dec 2013 18:08:53 -0000

On Tue, Dec 3, 2013 at 9:41 AM, Dan Harkins  wrote:
>
> On Tue, December 3, 2013 8:12 am, Watson Ladd wrote:
>> On Tue, Dec 3, 2013 at 12:50 AM, Dan Harkins  wrote=
:
>>>
>>> On Mon, December 2, 2013 8:40 am, Watson Ladd wrote:
>>>> On Mon, Dec 2, 2013 at 6:28 AM, Rene Struik 
>>>> wrote:
>>>>> Dear colleagues:
>>>>>
>>>>> I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work
>>>>> that
>>>>> went into this draft, I have to concur with some other commenters
>>>>> (e.g.,
>>>>> Doug Stebila, Bodo Moeller) that it is unclear what makes this
>>>>> protocol
>>>>> special compared to other contenders, both in terms of performance an=
d
>>>>> detailed cryptanalysis. One glaring omission is detailed security
>>>>> evidence,
>>>>> which is currently lacking (cross-referencing some other standards
>>>>> that
>>>>> have
>>>>> specified the protocol does not by itself imply the protocol is
>>>>> therefore
>>>>> secure). I am kind of curious what technical advantages the
>>>>> "Dragonfly"
>>>>> protocol has over protocols that seem to have efficiency, detailed an=
d
>>>>> crypto community reviewed evidence, such as, e.g., AugPAKE (which is
>>>>> another
>>>>> TLS-aimed draft) and others. So, if the TLS WG has considered a
>>>>> feature
>>>>> comparison, that would be good to share.
>>>>>
>>>>> I would recommend to ask CFRG to carefully review the corresponding
>>>>> irtf-dragonfly-02 document (to my knowledge, there has been no LC and
>>>>> it
>>>>> is
>>>>> still a draft document there) and align the TLS document
>>>>> draft-ietf-tls-pwd-02 document with whatever comes out of that effort
>>>>> (currently, there are some security-relevant differences). This time
>>>>> window
>>>>> could also be used for firming up security rationale, thus aleviating
>>>>> concerns on that front.
>>>> I do not like the way this standard mixes algorithmic details with
>>>> instantiation
>>>> details. It makes it hard for me to understand what the protocol
>>>> actually
>>>> is.
>>>> I also do not understand why H needs to be a random oracle as opposed
>>>> to
>>>> something we have in the standard model.
>>>
>>>   It is difficult to understand how to act on this comment. The
>>> specification
>>> is of a cipher suite added to an existing protocol and as such has to
>>> "mix" the
>>> details of the underlying key exchange with the structure and format of
>>> the
>>> protocol it is being added to. It is not a high-level description of th=
e
>>> algorithm,
>>> it is a description of how to implement the key exchange as a TLS ciphe=
r
>>> suit.
>> What protocol is this standard implementing? Where is it documented? Whe=
re
>> is
>> the security proof?
>
>   Do you have a specific comment on the draft itself? "I don't like it" i=
s an
> unactionable editorial comment.
Yes: the draft is unacceptable from a cryptographic perspective
because has a protocol
that has not faced formal analysis or review by the cryptographic
community, is not clearly
presented, and has no analysis worthy of the name.
The action is to write the protocol, formally prove it correct, submit
the paper to a conference
wait a few years, and then say "well, this works". Or use a theorem
verifier to shorten the time.
Rene Struik, Robert Ransom, and I all have the same opinion on the
merits of this protocol: questionable at best.
I believe this should be sufficient to prevent this draft from
becoming a standard.
>
>>>> I also do not like the language of "commitment" used. What is sent is
>>>> not a Pedersen commitment or any other recognizable commitment.
>>>> It is very malleable in ways that make me question the informal
>>>> security
>>>> analysis.
>>>
>>>   Of course it's a recognizable commitment because it allows the sender
>>> to commit to a particular value (the password) without exposing it to
>>> anyone else.
>> The sender is committed to the password, but not to the value of the PE
>> point.
>
>   There is a one-to-one mapping of password (plus username and salt)
> and point. If one is committed to the password, he's committed to the
> point.
No, because the point might not be from a password. He might not be able to=
 show
a password going to the point that he claims he was committed to, but
that doesn't necessarily
matter. Without a proof we have no idea how much it matters. Reading
the draft I don't think
the password needs to be guessed or known, but the point itself, and
the attacker isn't bound
to a choice of point.
>
>> This is noted in the "security analysis" section, but absent a proof I
>> can't tell you
>> that it doesn't matter. The security analysis section reads like a
>> bunch of attacks
>> were tried and failed. All that shows is *you* couldn't break it, not
>> that anyone else
>> couldn't.
>>>
>>>>> Two final comments:
>>>>> a) It is unclear why one should hard code in the draft that elliptic
>>>>> curves
>>>>> with co-factor h>1 would be ruled out. After all, this would make it
>>>>> much
>>>>> harder to extend the reach of the draft to prime curves with co-facto=
r
>>>>> larger than one and to binary curves.
>>>> I think the authors wanted to specify secure curves and haddn't the
>>>> slightest to do it right.
>>>
>>>   (Note: I always like to have my intelligence questioned with a
>>> statement
>>> that has multiple grammatical errors).
>> It's not your intell
>
>   Again, thank you for that comment.
>
As I ment to say, but due to an editing failure did not, it is not
your intelligence I am questioning
but your ability to do cryptographic work. The present draft shows no
evidence of it. Of course,
it turns out that you weren't attempting to specify secure curves, but
unpatented ones. But all
that matter is one curve has one implementation not reached by
patents, not that the standard can only be used with unpatented
implementations
>>>   As I mentioned to Rene, the reason for limiting the curves to those
>>> over a prime field with a co-factor of 1 is to avoid the patent mine
>>> field.
>> What mine field? What is so patented about cofactor>1 over prime field?
>> For binary curves I agree.
>
>   There are plenty of patents that deal with acceleration when the
> cofactor is > 1 or deal with verification of received elements when
> the cofactor is > 1. I just don't want to deal with it.
And so you preemptively limit the ability of implementers to use Ed25519 if
they feel confident that it is not patented, or they don't need the
"acceleration"
that you claim is patented. It might be worthwhile to say everyone support =
P256
so we can interoperate, but why rule out particular instantiations a
priori? I just don't
get the rationale here.
>
>>                                         But why not use whatever curve
> TLS specifies?
>> Also, why not use the existing mechanisms to deal with implementation
>> limits
>> caused by patents?
>
>   What mechanisms _speciifcally_ is TLS-pwd doing that is causing you
> to say this? It uses the existing mechanisms provided by the base TLS
> protocol to convey the group to use. Again, I don't know how to address
> a comment that says to change the protocol to do what it already does.
>
>>>> Weierstrau=C3=9F form has big problems: Edwards is much better from an
>>>> implementation security
>>>> perspective. Cofactor isn't enough: you also need high embedding
>>>> degree, big discriminant,
>>>> or you could just use curves we agree are good instead of reinventing
>>>> the
>>>> wheel.
>
>   "[U]se curves we all agree are good instead of reinventing the wheel"? =
Now
> I'm starting to think you didn't even read the draft.
We do not need 3 different places in the TLS handshake containing EC
curve parameters.
When a TLS client implementing this protocol talks to a server, it
will send this extension with
EC parameters, as well as EC parameters for the extensions permitting
EC ciphersuites to be used,
as well as special TLS ciphers saying it can use EC. This is ridiculous.
Any gains from specifying the curves are lost because of the strong
restrictions on shape.
It's entirely possible that this is the best possible result given the
current state of TLS, and my
objection to the mechanism is not strong: my strong objection is from
the lack of serious cryptographic
effort in this draft and that we have no idea how strong this protocol is.
>
>   Dan.
>
>>>> Higher order protocols should be group agnostic.This prevents a major
>>>> problem when
>>>> Joux comes up with something new.
>>>
>>>   It specifies a single group for interoperability purposes. It's
>>> "crypto
>>> agility" is inherited from TLS.
>>>
>>>   Dan.
>>>
>>>>> b) The probabilistic nature of the "hunting and pecking" procedure ma=
y
>>>>> be a
>>>>> recipe for triggering implementation attacks. Wouldn't one be much
>>>>> better
>>>>> off removing dependency on non-deterministic password-to-point
>>>>> mappings
>>>>> (e.g., AugPAKE, Icart map, German BSI-password protocol)?
>>>> Well, one could use Elligator to solve this problem.
>>>>>
>>>>> Best regards, Rene
>>>>>
>>>>>
>>>>> On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote:
>>>>>>
>>>>>> This is the beginning of the working group last call for
>>>>>> draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
>>>>>> TLS-PWD
>>>>>> has been reviewed by the IRTF CFRG group with satisfactory results.
>>>>>> The
>>>>>> document needs particular attention paid to the integration of this
>>>>>> mechanism into the TLS protocol.   Please send comments to the TLS
>>>>>> list
>>>>>> by
>>>>>> December 2, 2013.
>>>>>>
>>>>>> - Joe
>>>>>> (For the TLS chairs)
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>> _______________________________________________
>>>> 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
>>
>



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

From mbadra@gmail.com  Tue Dec  3 10:25:22 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025C91AD944 for ; Tue,  3 Dec 2013 10:25:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 2zpDZzv6B0Fl for ; Tue,  3 Dec 2013 10:25:17 -0800 (PST)
Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id A92C01AE16F for ; Tue,  3 Dec 2013 10:25:16 -0800 (PST)
Received: by mail-ve0-f179.google.com with SMTP id jw12so10516705veb.24 for ; Tue, 03 Dec 2013 10:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tsFmAh+CCvHGzw4jYNnkcZh/K+FHTxDuZOLs9kdYx4g=; b=xwE5vuZQmL2oPwUBusIPAxkWJ4yssie0IBzRgd0HJG1njWQFmaTr7KlYrN6Z5eQ7Aq 15r6fpGIN1QmiaBzq5/TfBUlx1Yem+0OBJGhTbdPxxtIIK3EIObqjLXWL5x+i6pCsX9V PTd470kYiIhOFnYFqrf62mi4jAl2vB+JIk2tZTIIxU6iwq6l59D2E1ddHt/4lBxsUWyl DWXkaCG0fdAOaRnICreF2Q4tyt4GPqQD1pFZJv/A3rOow2Sts1882OiJVFQ93XAKrL8C JNH4T24qFvZXLMiLs4/Ic/5dHMCwxZu5aFMRd+KYnctB55W6RGFROXIOWa5dESfciaq+ FUjg==
MIME-Version: 1.0
X-Received: by 10.220.50.18 with SMTP id x18mr106068vcf.29.1386095113479; Tue, 03 Dec 2013 10:25:13 -0800 (PST)
Received: by 10.221.43.138 with HTTP; Tue, 3 Dec 2013 10:25:13 -0800 (PST)
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net> 
Date: Tue, 3 Dec 2013 22:25:13 +0400
Message-ID: 
From: Mohamad Badra 
To: Watson Ladd 
Content-Type: multipart/alternative; boundary=047d7b34427add798704eca56aea
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 03 Dec 2013 18:25:22 -0000

--047d7b34427add798704eca56aea
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

For info, I submitted during 2007 and 2008 two documents to enable
authentication using passwords.

http://tools.ietf.org/id/draft-badra-tls-password-ext-01.txt
ftp://ftp.kfki.hu/pub/documents/iana/drafts/draft-badra-tls-password-00.txt

Both of them are simple, and secure enough to enable password-based
authentication

Best regards,
Badra



On Tue, Dec 3, 2013 at 10:08 PM, Watson Ladd  wrote:

> On Tue, Dec 3, 2013 at 9:41 AM, Dan Harkins  wrote:
> >
> > On Tue, December 3, 2013 8:12 am, Watson Ladd wrote:
> >> On Tue, Dec 3, 2013 at 12:50 AM, Dan Harkins 
> wrote:
> >>>
> >>> On Mon, December 2, 2013 8:40 am, Watson Ladd wrote:
> >>>> On Mon, Dec 2, 2013 at 6:28 AM, Rene Struik 
> >>>> wrote:
> >>>>> Dear colleagues:
> >>>>>
> >>>>> I had a look at draft-ietf-tls-pwd-02. While I do appreciate the wo=
rk
> >>>>> that
> >>>>> went into this draft, I have to concur with some other commenters
> >>>>> (e.g.,
> >>>>> Doug Stebila, Bodo Moeller) that it is unclear what makes this
> >>>>> protocol
> >>>>> special compared to other contenders, both in terms of performance
> and
> >>>>> detailed cryptanalysis. One glaring omission is detailed security
> >>>>> evidence,
> >>>>> which is currently lacking (cross-referencing some other standards
> >>>>> that
> >>>>> have
> >>>>> specified the protocol does not by itself imply the protocol is
> >>>>> therefore
> >>>>> secure). I am kind of curious what technical advantages the
> >>>>> "Dragonfly"
> >>>>> protocol has over protocols that seem to have efficiency, detailed
> and
> >>>>> crypto community reviewed evidence, such as, e.g., AugPAKE (which i=
s
> >>>>> another
> >>>>> TLS-aimed draft) and others. So, if the TLS WG has considered a
> >>>>> feature
> >>>>> comparison, that would be good to share.
> >>>>>
> >>>>> I would recommend to ask CFRG to carefully review the corresponding
> >>>>> irtf-dragonfly-02 document (to my knowledge, there has been no LC a=
nd
> >>>>> it
> >>>>> is
> >>>>> still a draft document there) and align the TLS document
> >>>>> draft-ietf-tls-pwd-02 document with whatever comes out of that effo=
rt
> >>>>> (currently, there are some security-relevant differences). This tim=
e
> >>>>> window
> >>>>> could also be used for firming up security rationale, thus aleviati=
ng
> >>>>> concerns on that front.
> >>>> I do not like the way this standard mixes algorithmic details with
> >>>> instantiation
> >>>> details. It makes it hard for me to understand what the protocol
> >>>> actually
> >>>> is.
> >>>> I also do not understand why H needs to be a random oracle as oppose=
d
> >>>> to
> >>>> something we have in the standard model.
> >>>
> >>>   It is difficult to understand how to act on this comment. The
> >>> specification
> >>> is of a cipher suite added to an existing protocol and as such has to
> >>> "mix" the
> >>> details of the underlying key exchange with the structure and format =
of
> >>> the
> >>> protocol it is being added to. It is not a high-level description of
> the
> >>> algorithm,
> >>> it is a description of how to implement the key exchange as a TLS
> cipher
> >>> suit.
> >> What protocol is this standard implementing? Where is it documented?
> Where
> >> is
> >> the security proof?
> >
> >   Do you have a specific comment on the draft itself? "I don't like it"
> is an
> > unactionable editorial comment.
> Yes: the draft is unacceptable from a cryptographic perspective
> because has a protocol
> that has not faced formal analysis or review by the cryptographic
> community, is not clearly
> presented, and has no analysis worthy of the name.
> The action is to write the protocol, formally prove it correct, submit
> the paper to a conference
> wait a few years, and then say "well, this works". Or use a theorem
> verifier to shorten the time.
> Rene Struik, Robert Ransom, and I all have the same opinion on the
> merits of this protocol: questionable at best.
> I believe this should be sufficient to prevent this draft from
> becoming a standard.
> >
> >>>> I also do not like the language of "commitment" used. What is sent i=
s
> >>>> not a Pedersen commitment or any other recognizable commitment.
> >>>> It is very malleable in ways that make me question the informal
> >>>> security
> >>>> analysis.
> >>>
> >>>   Of course it's a recognizable commitment because it allows the send=
er
> >>> to commit to a particular value (the password) without exposing it to
> >>> anyone else.
> >> The sender is committed to the password, but not to the value of the P=
E
> >> point.
> >
> >   There is a one-to-one mapping of password (plus username and salt)
> > and point. If one is committed to the password, he's committed to the
> > point.
> No, because the point might not be from a password. He might not be able
> to show
> a password going to the point that he claims he was committed to, but
> that doesn't necessarily
> matter. Without a proof we have no idea how much it matters. Reading
> the draft I don't think
> the password needs to be guessed or known, but the point itself, and
> the attacker isn't bound
> to a choice of point.
> >
> >> This is noted in the "security analysis" section, but absent a proof I
> >> can't tell you
> >> that it doesn't matter. The security analysis section reads like a
> >> bunch of attacks
> >> were tried and failed. All that shows is *you* couldn't break it, not
> >> that anyone else
> >> couldn't.
> >>>
> >>>>> Two final comments:
> >>>>> a) It is unclear why one should hard code in the draft that ellipti=
c
> >>>>> curves
> >>>>> with co-factor h>1 would be ruled out. After all, this would make i=
t
> >>>>> much
> >>>>> harder to extend the reach of the draft to prime curves with
> co-factor
> >>>>> larger than one and to binary curves.
> >>>> I think the authors wanted to specify secure curves and haddn't the
> >>>> slightest to do it right.
> >>>
> >>>   (Note: I always like to have my intelligence questioned with a
> >>> statement
> >>> that has multiple grammatical errors).
> >> It's not your intell
> >
> >   Again, thank you for that comment.
> >
> As I ment to say, but due to an editing failure did not, it is not
> your intelligence I am questioning
> but your ability to do cryptographic work. The present draft shows no
> evidence of it. Of course,
> it turns out that you weren't attempting to specify secure curves, but
> unpatented ones. But all
> that matter is one curve has one implementation not reached by
> patents, not that the standard can only be used with unpatented
> implementations
> >>>   As I mentioned to Rene, the reason for limiting the curves to those
> >>> over a prime field with a co-factor of 1 is to avoid the patent mine
> >>> field.
> >> What mine field? What is so patented about cofactor>1 over prime field=
?
> >> For binary curves I agree.
> >
> >   There are plenty of patents that deal with acceleration when the
> > cofactor is > 1 or deal with verification of received elements when
> > the cofactor is > 1. I just don't want to deal with it.
> And so you preemptively limit the ability of implementers to use Ed25519 =
if
> they feel confident that it is not patented, or they don't need the
> "acceleration"
> that you claim is patented. It might be worthwhile to say everyone suppor=
t
> P256
> so we can interoperate, but why rule out particular instantiations a
> priori? I just don't
> get the rationale here.
> >
> >>                                         But why not use whatever curve
> > TLS specifies?
> >> Also, why not use the existing mechanisms to deal with implementation
> >> limits
> >> caused by patents?
> >
> >   What mechanisms _speciifcally_ is TLS-pwd doing that is causing you
> > to say this? It uses the existing mechanisms provided by the base TLS
> > protocol to convey the group to use. Again, I don't know how to address
> > a comment that says to change the protocol to do what it already does.
> >
> >>>> Weierstrau=DF form has big problems: Edwards is much better from an
> >>>> implementation security
> >>>> perspective. Cofactor isn't enough: you also need high embedding
> >>>> degree, big discriminant,
> >>>> or you could just use curves we agree are good instead of reinventin=
g
> >>>> the
> >>>> wheel.
> >
> >   "[U]se curves we all agree are good instead of reinventing the wheel"=
?
> Now
> > I'm starting to think you didn't even read the draft.
> We do not need 3 different places in the TLS handshake containing EC
> curve parameters.
> When a TLS client implementing this protocol talks to a server, it
> will send this extension with
> EC parameters, as well as EC parameters for the extensions permitting
> EC ciphersuites to be used,
> as well as special TLS ciphers saying it can use EC. This is ridiculous.
> Any gains from specifying the curves are lost because of the strong
> restrictions on shape.
> It's entirely possible that this is the best possible result given the
> current state of TLS, and my
> objection to the mechanism is not strong: my strong objection is from
> the lack of serious cryptographic
> effort in this draft and that we have no idea how strong this protocol is=
.
> >
> >   Dan.
> >
> >>>> Higher order protocols should be group agnostic.This prevents a majo=
r
> >>>> problem when
> >>>> Joux comes up with something new.
> >>>
> >>>   It specifies a single group for interoperability purposes. It's
> >>> "crypto
> >>> agility" is inherited from TLS.
> >>>
> >>>   Dan.
> >>>
> >>>>> b) The probabilistic nature of the "hunting and pecking" procedure
> may
> >>>>> be a
> >>>>> recipe for triggering implementation attacks. Wouldn't one be much
> >>>>> better
> >>>>> off removing dependency on non-deterministic password-to-point
> >>>>> mappings
> >>>>> (e.g., AugPAKE, Icart map, German BSI-password protocol)?
> >>>> Well, one could use Elligator to solve this problem.
> >>>>>
> >>>>> Best regards, Rene
> >>>>>
> >>>>>
> >>>>> On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote:
> >>>>>>
> >>>>>> This is the beginning of the working group last call for
> >>>>>> draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
> >>>>>> TLS-PWD
> >>>>>> has been reviewed by the IRTF CFRG group with satisfactory results=
.
> >>>>>> The
> >>>>>> document needs particular attention paid to the integration of thi=
s
> >>>>>> mechanism into the TLS protocol.   Please send comments to the TLS
> >>>>>> list
> >>>>>> by
> >>>>>> December 2, 2013.
> >>>>>>
> >>>>>> - Joe
> >>>>>> (For the TLS chairs)
> >>>>>> _______________________________________________
> >>>>>> 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
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>> _______________________________________________
> >>>> 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
> >>
> >
>
>
>
> --
> "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
>

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


For info, I submitted during 2007 and 2008 two documents t=
o enable authentication using passwords.=A0




Both of them are simple, an=
d secure enough to enable password-based authentication



Best regards,
Badra

<=
/div>


On Tue, =
Dec 3, 2013 at 10:08 PM, Watson Ladd <watsonbladd@gmail.com> wrote:


On T=
ue, Dec 3, 2013 at 9:41 AM, Dan Harkins <dharkins@lounge.org> wrote:


>

> On Tue, December 3, 2013 8:12 am, Watson Ladd wrote:

>> On Tue, Dec 3, 2013 at 12:50 AM, Dan Harkins <dharkins@lounge.org> wrote:

>>>

>>> On Mon, December 2, 2013 8:40 am, Watson Ladd wrote:

>>>> On Mon, Dec 2, 2013 at 6:28 AM, Rene Struik <rstruik.ext@gmail.com>

>>>> wrote:

>>>>> Dear colleagues:

>>>>>

>>>>> I had a look at draft-ietf-tls-pwd-02. While I do appr=
eciate the work

>>>>> that

>>>>> went into this draft, I have to concur with some other=
 commenters

>>>>> (e.g.,

>>>>> Doug Stebila, Bodo Moeller) that it is unclear what ma=
kes this

>>>>> protocol

>>>>> special compared to other contenders, both in terms of=
 performance and

>>>>> detailed cryptanalysis. One glaring omission is detail=
ed security

>>>>> evidence,

>>>>> which is currently lacking (cross-referencing some oth=
er standards

>>>>> that

>>>>> have

>>>>> specified the protocol does not by itself imply the pr=
otocol is

>>>>> therefore

>>>>> secure). I am kind of curious what technical advantage=
s the

>>>>> "Dragonfly"

>>>>> protocol has over protocols that seem to have efficien=
cy, detailed and

>>>>> crypto community reviewed evidence, such as, e.g., Aug=
PAKE (which is

>>>>> another

>>>>> TLS-aimed draft) and others. So, if the TLS WG has con=
sidered a

>>>>> feature

>>>>> comparison, that would be good to share.

>>>>>

>>>>> I would recommend to ask CFRG to carefully review the =
corresponding

>>>>> irtf-dragonfly-02 document (to my knowledge, there has=
 been no LC and

>>>>> it

>>>>> is

>>>>> still a draft document there) and align the TLS docume=
nt

>>>>> draft-ietf-tls-pwd-02 document with whatever comes out=
 of that effort

>>>>> (currently, there are some security-relevant differenc=
es). This time

>>>>> window

>>>>> could also be used for firming up security rationale, =
thus aleviating

>>>>> concerns on that front.

>>>> I do not like the way this standard mixes algorithmic deta=
ils with

>>>> instantiation

>>>> details. It makes it hard for me to understand what the pr=
otocol

>>>> actually

>>>> is.

>>>> I also do not understand why H needs to be a random oracle=
 as opposed

>>>> to

>>>> something we have in the standard model.

>>>

>>> =A0 It is difficult to understand how to act on this comment. =
The

>>> specification

>>> is of a cipher suite added to an existing protocol and as such=
 has to

>>> "mix" the

>>> details of the underlying key exchange with the structure and =
format of

>>> the

>>> protocol it is being added to. It is not a high-level descript=
ion of the

>>> algorithm,

>>> it is a description of how to implement the key exchange as a =
TLS cipher

>>> suit.

>> What protocol is this standard implementing? Where is it documente=
d? Where

>> is

>> the security proof?

>

> =A0 Do you have a specific comment on the draft itself? "I don=
9;t like it" is an

> unactionable editorial comment.


Yes: the draft is unacceptable from a cryptographic perspective=


because has a protocol

that has not faced formal analysis or review by the cryptographic

community, is not clearly

presented, and has no analysis worthy of the name.

The action is to write the protocol, formally prove it correct, submit

the paper to a conference

wait a few years, and then say "well, this works". Or use a theor=
em

verifier to shorten the time.

Rene Struik, Robert Ransom, and I all have the same opinion on the

merits of this protocol: questionable at best.

I believe this should be sufficient to prevent this draft from

becoming a standard.


>

>>>> I also do not like the language of "commitment" =
used. What is sent is

>>>> not a Pedersen commitment or any other recognizable commit=
ment.

>>>> It is very malleable in ways that make me question the inf=
ormal

>>>> security

>>>> analysis.

>>>

>>> =A0 Of course it's a recognizable commitment because it al=
lows the sender

>>> to commit to a particular value (the password) without exposin=
g it to

>>> anyone else.

>> The sender is committed to the password, but not to the value of t=
he PE

>> point.

>

> =A0 There is a one-to-one mapping of password (plus username and salt)=


> and point. If one is committed to the password, he's committed to =
the

> point.


No, because the point might not be from a password. He might not be a=
ble to show

a password going to the point that he claims he was committed to, but

that doesn't necessarily

matter. Without a proof we have no idea how much it matters. Reading

the draft I don't think

the password needs to be guessed or known, but the point itself, and

the attacker isn't bound

to a choice of point.


>

>> This is noted in the "security analysis" section, but ab=
sent a proof I

>> can't tell you

>> that it doesn't matter. The security analysis section reads li=
ke a

>> bunch of attacks

>> were tried and failed. All that shows is *you* couldn't break =
it, not

>> that anyone else

>> couldn't.

>>>

>>>>> Two final comments:

>>>>> a) It is unclear why one should hard code in the draft=
 that elliptic

>>>>> curves

>>>>> with co-factor h>1 would be ruled out. After all, t=
his would make it

>>>>> much

>>>>> harder to extend the reach of the draft to prime curve=
s with co-factor

>>>>> larger than one and to binary curves.

>>>> I think the authors wanted to specify secure curves and ha=
ddn't the

>>>> slightest to do it right.

>>>

>>> =A0 (Note: I always like to have my intelligence questioned wi=
th a

>>> statement

>>> that has multiple grammatical errors).

>> It's not your intell

>

> =A0 Again, thank you for that comment.

>


As I ment to say, but due to an editing failure did not, it is not
your intelligence I am questioning

but your ability to do cryptographic work. The present draft shows no

evidence of it. Of course,

it turns out that you weren't attempting to specify secure curves, but<=
br>
unpatented ones. But all

that matter is one curve has one implementation not reached by

patents, not that the standard can only be used with unpatented

implementations


>>> =A0 As I mentioned to Rene, the reason for l=
imiting the curves to those

>>> over a prime field with a co-factor of 1 is to avoid the paten=
t mine

>>> field.

>> What mine field? What is so patented about cofactor>1 over prim=
e field?

>> For binary curves I agree.

>

> =A0 There are plenty of patents that deal with acceleration when the
> cofactor is > 1 or deal with verification of received elements when=


> the cofactor is > 1. I just don't want to deal with it.


And so you preemptively limit the ability of implementers to use Ed25=
519 if

they feel confident that it is not patented, or they don't need the

"acceleration"

that you claim is patented. It might be worthwhile to say everyone support =
P256

so we can interoperate, but why rule out particular instantiations a

priori? I just don't

get the rationale here.


>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 But why not use whatever curve

> TLS specifies?

>> Also, why not use the existing mechanisms to deal with implementat=
ion

>> limits

>> caused by patents?

>

> =A0 What mechanisms _speciifcally_ is TLS-pwd doing that is causing yo=
u

> to say this? It uses the existing mechanisms provided by the base TLS<=
br>
> protocol to convey the group to use. Again, I don't know how to ad=
dress

> a comment that says to change the protocol to do what it already does.=


>


>>>> Weierstrau=DF form has big problems: Edwards is much=
 better from an


>>>> implementation security

>>>> perspective. Cofactor isn't enough: you also need high=
 embedding

>>>> degree, big discriminant,

>>>> or you could just use curves we agree are good instead of =
reinventing

>>>> the

>>>> wheel.

>

> =A0 "[U]se curves we all agree are good instead of reinventing th=
e wheel"? Now

> I'm starting to think you didn't even read the draft.


We do not need 3 different places in the TLS handshake containing EC<=
br>
curve parameters.

When a TLS client implementing this protocol talks to a server, it

will send this extension with

EC parameters, as well as EC parameters for the extensions permitting

EC ciphersuites to be used,

as well as special TLS ciphers saying it can use EC. This is ridiculous.
Any gains from specifying the curves are lost because of the strong

restrictions on shape.

It's entirely possible that this is the best possible result given the<=
br>
current state of TLS, and my

objection to the mechanism is not strong: my strong objection is from

the lack of serious cryptographic

effort in this draft and that we have no idea how strong this protocol is.<=
br>

>

> =A0 Dan.

>

>>>> Higher order protocols should be group agnostic.This preve=
nts a major

>>>> problem when

>>>> Joux comes up with something new.

>>>

>>> =A0 It specifies a single group for interoperability purposes.=
 It's

>>> "crypto

>>> agility" is inherited from TLS.

>>>

>>> =A0 Dan.

>>>

>>>>> b) The probabilistic nature of the "hunting and p=
ecking" procedure may

>>>>> be a

>>>>> recipe for triggering implementation attacks. Wouldn&#=
39;t one be much

>>>>> better

>>>>> off removing dependency on non-deterministic password-=
to-point

>>>>> mappings

>>>>> (e.g., AugPAKE, Icart map, German BSI-password protoco=
l)?

>>>> Well, one could use Elligator to solve this problem.

>>>>>

>>>>> Best regards, Rene

>>>>>

>>>>>

>>>>> On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote:=


>>>>>>

>>>>>> This is the beginning of the working group last ca=
ll for

>>>>>> draft-ietf-tls-pwd-01. =A0 The underlying cryptogr=
aphic protocol for

>>>>>> TLS-PWD

>>>>>> has been reviewed by the IRTF CFRG group with sati=
sfactory results.

>>>>>> The

>>>>>> document needs particular attention paid to the in=
tegration of this

>>>>>> mechanism into the TLS protocol. =A0 Please send c=
omments to the TLS

>>>>>> list

>>>>>> by

>>>>>> December 2, 2013.

>>>>>>

>>>>>> - Joe

>>>>>> (For the TLS chairs)

>>>>>> _______________________________________________
>>>>>> TLS mailing list

>>>>>> TLS@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/tls

>>>>>

>>>>>

>>>>>

>>>>> --

>>>>> email: rstrui=
k.ext@gmail.com | Skype: rstruik

>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

>>>>>

>>>>>

>>>>> _______________________________________________

>>>>> TLS mailing list

>>>>> TLS@ietf.org

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

>>>>

>>>>

>>>>

>>>> --

>>>> "Those who would give up Essential Liberty to purchas=
e a little

>>>> Temporary Safety deserve neither =A0Liberty nor Safety.&qu=
ot;

>>>> -- Benjamin Franklin

>>>> _______________________________________________

>>>> TLS mailing list

>>>> TLS@ietf.org

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

>>>>

>>>

>>>

>>

>>

>>

>> --

>> "Those who would give up Essential Liberty to purchase a litt=
le

>> Temporary Safety deserve neither =A0Liberty nor Safety."

>> -- Benjamin Franklin

>>

>







--

"Those who would give up Essential Liberty to purchase a little

Temporary Safety deserve neither =A0Liberty nor Safety."

-- Benjamin Franklin

_______________________________________________

TLS mailing list

TLS@ietf.org

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





--047d7b34427add798704eca56aea--

From Kenny.Paterson@rhul.ac.uk  Tue Dec  3 11:12:33 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CD91A8032 for ; Tue,  3 Dec 2013 11:12:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 R9-hPT6GCjCL for ; Tue,  3 Dec 2013 11:12:30 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 19EF91ACCDE for ; Tue,  3 Dec 2013 11:12:29 -0800 (PST)
Received: from mail3-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 Dec 2013 19:12:27 +0000
Received: from mail3-ch1 (localhost [127.0.0.1])	by mail3-ch1-R.bigfish.com (Postfix) with ESMTP id 21160E039F;	Tue,  3 Dec 2013 19:12:27 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.149; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0311HT004.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -20
X-BigFish: PS-20(zzc89bh542I1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2dh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h9a9j1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(199002)(189002)(51704005)(81342001)(56776001)(15202345003)(74316001)(85306002)(54316002)(53806001)(19580405001)(74662001)(90146001)(56816005)(85852002)(76796001)(81686001)(76786001)(87266001)(74502001)(81542001)(54356001)(59766001)(79102001)(74366001)(77982001)(2656002)(83322001)(15975445006)(47736001)(49866001)(76576001)(50986001)(4396001)(74876001)(47446002)(83072001)(80976001)(33646001)(46102001)(19580395003)(81816001)(31966008)(51856001)(47976001)(76482001)(69226001)(74482001)(66066001)(74706001)(87936001)(63696002)(65816001)(80022001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DB4PR03MB380; H:DB4PR03MB377.eurprd03.prod.outlook.com; CLIP:134.219.148.47; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail3-ch1 (localhost.localdomain [127.0.0.1]) by mail3-ch1 (MessageSwitch) id 1386097944954624_22489; Tue,  3 Dec 2013 19:12:24 +0000 (UTC)
Received: from CH1EHSMHS034.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.243])	by mail3-ch1.bigfish.com (Postfix) with ESMTP id E3A6B3C00D2; Tue,  3 Dec 2013 19:12:24 +0000 (UTC)
Received: from AM2PRD0311HT004.eurprd03.prod.outlook.com (157.56.249.149) by CH1EHSMHS034.bigfish.com (10.43.70.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 3 Dec 2013 19:12:24 +0000
Received: from DB4PR03MB380.eurprd03.prod.outlook.com (10.242.231.18) by AM2PRD0311HT004.eurprd03.prod.outlook.com (10.255.162.39) with Microsoft SMTP Server (TLS) id 14.16.383.1; Tue, 3 Dec 2013 19:12:23 +0000
Received: from DB4PR03MB377.eurprd03.prod.outlook.com (10.242.231.12) by DB4PR03MB380.eurprd03.prod.outlook.com (10.242.231.18) with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 3 Dec 2013 19:12:22 +0000
Received: from DB4PR03MB377.eurprd03.prod.outlook.com ([10.242.231.12]) by DB4PR03MB377.eurprd03.prod.outlook.com ([10.242.231.12]) with mapi id 15.00.0820.005; Tue, 3 Dec 2013 19:12:21 +0000
From: "Paterson, Kenny" 
To: "mrex@sap.com" , =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= 
Thread-Topic: [TLS] Encrypt-then-MAC again (was Re: padding bug)
Thread-Index: AQHO7R77H2f5vAeCGkOkJhCJPGzqVZo8bsWAgAA2+ACABhAcAA==
Date: Tue, 3 Dec 2013 19:12:21 +0000
Message-ID: 
References: <37189D49-4190-4DCA-B6E8-C46226D9F51E@iki.fi> <20131129201714.A6B031AB11@ld9781.wdf.sap.corp>
In-Reply-To: <20131129201714.A6B031AB11@ld9781.wdf.sap.corp>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.219.148.47]
x-forefront-prvs: 0049B3F387
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "" , Peter Gutmann 
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 03 Dec 2013 19:12:33 -0000

Hi Martin,

> -----Original Message-----
> From: Martin Rex
> Sent: 29 November 2013 20:17
> To: Juho V=E4h=E4-Herttua
> Cc: ; Peter Gutmann
> Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
>=20
> >
> > I'm sure you have good reasons for this opposition, so could you
> > please explain them in one or two sentences. This excluding the
> > "encrypting the HMAC makes it safer" argument, which might be true but
> > as I understand is not well proven.
>=20
> The fact that GHASH must be encrypted is sufficient proof that an encrypt=
ed
> MAC provides a better safety margin than a plaintext MAC.
>=20

You seem to be making the assumption that GHASH is a MAC algorithm. It's no=
t.
It's a universal hash function, that is, a function designed so that a part=
icular bound on the=20
probability of collision holds when the hash key is chosen uniformly at ran=
dom, quantified over
all possible pairs of input messages. See

http://en.wikipedia.org/wiki/Universal_hashing

for definitions.

GHASH is not itself intended to provide the unforgeability properties that =
we expect from a MAC.

In more detail, this kind of hash function can serve as the basis for build=
ing a MAC, but cannot be=20
used alone for that purpose. A fairly standard construction that uses a uni=
versal hash function like=20
GHASH to build a MAC is to mask the GHASH output using a pseudorandom value=
 computed using=20
a (second) secret key. =20

In AES-GCM, the security proof allows this pseudorandom value to be generat=
ed using the
encryption key with counter mode of AES, which happens to be the same mode =
used for=20
encryption of the plaintext. This is convenient for implementation, but not=
 a necessary=20
feature for building a MAC from a universal hash function.

So I don't believe it is either helpful or correct to cite GHASH as evidenc=
e that=20
MAC-then-encrypt provides a better safety margin than a plaintext MAC.

> MAC in the clear is only safe when the MAC algorithm is sufficiently clos=
e to
> perfect.  We know painfully well that our hash algorithms are *not* perfe=
ct, so
> I'm against taking chances, in particular for the GenericBlockCipher PDU.

Here you first refer to MAC algorithms needing to be perfect, then hash alg=
orithms=20
not being perfect. But these are different things. And all the evidence fro=
m the cryptographic
literature suggests that attacks on hash functions do not tidily convert in=
to attacks on MAC
algorithms built from these hash functions (I refer here to the significant=
 body of research on this
topic, including but not limited to: Fouque et al at Crypto 2007, L. Wang e=
t al. at Eurocrypt 2008,=20
X. Wang et al. at Eurocrypt 2009, and more recent work, e.g. Peyrin et al. =
at Asiacrypt 2012).

Cheers

Kenny=20


From dharkins@lounge.org  Tue Dec  3 11:21:07 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435151ADA74 for ; Tue,  3 Dec 2013 11:21:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 BtDKgYIDcaJS for ; Tue,  3 Dec 2013 11:21:04 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 671861AD8EC for ; Tue,  3 Dec 2013 11:21:04 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9D06F1022404A; Tue,  3 Dec 2013 11:21:01 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 3 Dec 2013 11:21:01 -0800 (PST)
Message-ID: <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net> 
Date: Tue, 3 Dec 2013 11:21:01 -0800 (PST)
From: "Dan Harkins" 
To: "Watson Ladd" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 03 Dec 2013 19:21:07 -0000

On Tue, December 3, 2013 10:08 am, Watson Ladd wrote:
> On Tue, Dec 3, 2013 at 9:41 AM, Dan Harkins  wrote:
[snip]
>>   Do you have a specific comment on the draft itself? "I don't like it"
>> is an
>> unactionable editorial comment.
> Yes: the draft is unacceptable from a cryptographic perspective
> because has a protocol
> that has not faced formal analysis or review by the cryptographic
> community, is not clearly
> presented, and has no analysis worthy of the name.
> The action is to write the protocol, formally prove it correct, submit
> the paper to a conference
> wait a few years, and then say "well, this works". Or use a theorem
> verifier to shorten the time.
> Rene Struik, Robert Ransom, and I all have the same opinion on the
> merits of this protocol: questionable at best.
> I believe this should be sufficient to prevent this draft from
> becoming a standard.

  That is not a comment on the draft but on the process.

  Nothing is stopping you from working on some protocol that you
find value in and working to achieve consensus on it being the right
way to go but work was done on this protocol and consensus was
reached in the WG to proceed with it. The exchange was reviewed
by the CFRG with, as Joe noted, satisfactory results.

  You think that is unacceptable? OK, point noted.

>>>>> I also do not like the language of "commitment" used. What is sent is
>>>>> not a Pedersen commitment or any other recognizable commitment.
>>>>> It is very malleable in ways that make me question the informal
>>>>> security
>>>>> analysis.
>>>>
>>>>   Of course it's a recognizable commitment because it allows the
>>>> sender
>>>> to commit to a particular value (the password) without exposing it to
>>>> anyone else.
>>> The sender is committed to the password, but not to the value of the PE
>>> point.
>>
>>   There is a one-to-one mapping of password (plus username and salt)
>> and point. If one is committed to the password, he's committed to the
>> point.
> No, because the point might not be from a password. He might not be able
> to show
> a password going to the point that he claims he was committed to, but
> that doesn't necessarily
> matter. Without a proof we have no idea how much it matters. Reading
> the draft I don't think
> the password needs to be guessed or known, but the point itself, and
> the attacker isn't bound
> to a choice of point.

  No, the attacker is free to choose any point he wants. But since there is
a one-to-one mapping of password (plus username plus salt) to point
any guess of the password that is incorrect will produce the wrong point.
That's the whole point (pun intended).

>>> This is noted in the "security analysis" section, but absent a proof I
>>> can't tell you
>>> that it doesn't matter. The security analysis section reads like a
>>> bunch of attacks
>>> were tried and failed. All that shows is *you* couldn't break it, not
>>> that anyone else
>>> couldn't.
>>>>
>>>>>> Two final comments:
>>>>>> a) It is unclear why one should hard code in the draft that elliptic
>>>>>> curves
>>>>>> with co-factor h>1 would be ruled out. After all, this would make it
>>>>>> much
>>>>>> harder to extend the reach of the draft to prime curves with
>>>>>> co-factor
>>>>>> larger than one and to binary curves.
>>>>> I think the authors wanted to specify secure curves and haddn't the
>>>>> slightest to do it right.
>>>>
>>>>   (Note: I always like to have my intelligence questioned with a
>>>> statement
>>>> that has multiple grammatical errors).
>>> It's not your intell
>>
>>   Again, thank you for that comment.
>>
> As I ment to say, but due to an editing failure did not, it is not
> your intelligence I am questioning
> but your ability to do cryptographic work. The present draft shows no
> evidence of it.

  Whether you're questioning my intelligence or my ability to do crypto
is another unactionable editorial comment. And frankly I don't really
care whether you are impressed with my abilities or not.

>                        Of course,
> it turns out that you weren't attempting to specify secure curves, but
> unpatented ones. But all
> that matter is one curve has one implementation not reached by
> patents, not that the standard can only be used with unpatented
> implementations

  No, I'm not specifying any curves. I'm just disallowing certain ones.

>>>>   As I mentioned to Rene, the reason for limiting the curves to those
>>>> over a prime field with a co-factor of 1 is to avoid the patent mine
>>>> field.
>>> What mine field? What is so patented about cofactor>1 over prime field?
>>> For binary curves I agree.
>>
>>   There are plenty of patents that deal with acceleration when the
>> cofactor is > 1 or deal with verification of received elements when
>> the cofactor is > 1. I just don't want to deal with it.
> And so you preemptively limit the ability of implementers to use Ed25519
> if
> they feel confident that it is not patented, or they don't need the
> "acceleration"
> that you claim is patented. It might be worthwhile to say everyone support
> P256
> so we can interoperate, but why rule out particular instantiations a
> priori? I just don't
> get the rationale here.

   Because patents tend to be written generally to cover more than
"particular instantiations".

>>>                                         But why not use whatever curve
>> TLS specifies?
>>> Also, why not use the existing mechanisms to deal with implementation
>>> limits
>>> caused by patents?
>>
>>   What mechanisms _speciifcally_ is TLS-pwd doing that is causing you
>> to say this? It uses the existing mechanisms provided by the base TLS
>> protocol to convey the group to use. Again, I don't know how to address
>> a comment that says to change the protocol to do what it already does.
>>
>>>>> Weierstrauß form has big problems: Edwards is much better from an
>>>>> implementation security
>>>>> perspective. Cofactor isn't enough: you also need high embedding
>>>>> degree, big discriminant,
>>>>> or you could just use curves we agree are good instead of reinventing
>>>>> the
>>>>> wheel.
>>
>>   "[U]se curves we all agree are good instead of reinventing the wheel"?
>> Now
>> I'm starting to think you didn't even read the draft.
> We do not need 3 different places in the TLS handshake containing EC
> curve parameters.
> When a TLS client implementing this protocol talks to a server, it
> will send this extension with
> EC parameters, as well as EC parameters for the extensions permitting
> EC ciphersuites to be used,
> as well as special TLS ciphers saying it can use EC. This is ridiculous.

  I don't think you understand how TLS works. It is necessary to convey
the particular curve to use and it is necessary to convey the information
required by the key exchange (i.e. the commitment).

  Again, if you have a _specific_ comment on how to do this differently,
I'm all ears. As was mentioned in the last call notice, "[t]he document
needs particular attention paid to the integration of this mechanism
into the TLS protocol." You seem to imply you have some way to
improve its integration into the TLS protocol. So instead of questioning
my ability or expressing your personal dissatisfaction that not enough
papers were written and years passed before this draft was written
maybe you can make a concrete and relevant comment to help improve
things. If not, then thank you for your most impressive soliloquy on
Edwards curves, Weierstrauss, big discriminants and the ever-fearful
"what will Joux do next".

  Dan.

> Any gains from specifying the curves are lost because of the strong
> restrictions on shape.
> It's entirely possible that this is the best possible result given the
> current state of TLS, and my
> objection to the mechanism is not strong: my strong objection is from
> the lack of serious cryptographic
> effort in this draft and that we have no idea how strong this protocol is.
>>
>>   Dan.
>>
>>>>> Higher order protocols should be group agnostic.This prevents a major
>>>>> problem when
>>>>> Joux comes up with something new.
>>>>
>>>>   It specifies a single group for interoperability purposes. It's
>>>> "crypto
>>>> agility" is inherited from TLS.
>>>>
>>>>   Dan.
>>>>
>>>>>> b) The probabilistic nature of the "hunting and pecking" procedure
>>>>>> may
>>>>>> be a
>>>>>> recipe for triggering implementation attacks. Wouldn't one be much
>>>>>> better
>>>>>> off removing dependency on non-deterministic password-to-point
>>>>>> mappings
>>>>>> (e.g., AugPAKE, Icart map, German BSI-password protocol)?
>>>>> Well, one could use Elligator to solve this problem.
>>>>>>
>>>>>> Best regards, Rene
>>>>>>
>>>>>>
>>>>>> On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote:
>>>>>>>
>>>>>>> This is the beginning of the working group last call for
>>>>>>> draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
>>>>>>> TLS-PWD
>>>>>>> has been reviewed by the IRTF CFRG group with satisfactory results.
>>>>>>> The
>>>>>>> document needs particular attention paid to the integration of this
>>>>>>> mechanism into the TLS protocol.   Please send comments to the TLS
>>>>>>> list
>>>>>>> by
>>>>>>> December 2, 2013.
>>>>>>>
>>>>>>> - Joe
>>>>>>> (For the TLS chairs)
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>
>
>
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
>


From dharkins@lounge.org  Tue Dec  3 14:51:55 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C38F1AE164 for ; Tue,  3 Dec 2013 14:51:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 75QICbeIelWB for ; Tue,  3 Dec 2013 14:51:52 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 89F011ADED9 for ; Tue,  3 Dec 2013 14:51:52 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 749C4A888012; Tue,  3 Dec 2013 14:51:49 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 3 Dec 2013 14:51:49 -0800 (PST)
Message-ID: <07e8735a16897ea72465ffb12f7a744f.squirrel@www.trepanning.net>
In-Reply-To: <529DE795.5060203@gmail.com>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> <6b51bc68470b316cf6d38c7033c0d451.squirrel@www.trepanning.net> <529DE795.5060203@gmail.com>
Date: Tue, 3 Dec 2013 14:51:49 -0800 (PST)
From: "Dan Harkins" 
To: "Rene Struik" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 03 Dec 2013 22:51:55 -0000

  Hi Rene,

On Tue, December 3, 2013 6:15 am, Rene Struik wrote:
> Hi Dan:
>
> I could not find that CFRG had a LC on this. In case I missed this,
> please kindly provide a pointer.
>
> Triggered by the TLS WG LC, I decided the review the Dragonfly protocol
> document last Friday (since TLS WG LC suggested CFRG had "blessed" this)
> and sent my review to the CFRG email reflector. One can find this review
> here:http://permalink.gmane.org/gmane.ietf.irtf.cfrg/2127
> .
>
> I suggest you have a discussion on how to fix security comments raised
> on the CFRG dragonfly protocol on that list.

  Already done. Thank you for your comments there, they will improve the
document. As you noted there your "review comments… *strictly* apply
to the latest CFRG draft only; the related TLS draft will be dealt with
separately." So I'm glad these two are not linked in your mind.

> As far as I am concerned, my TLS WGLC comments still stand.

  So what would you like me to do about them? Please comment below.

> Best regards, Rene
>
> On 12/3/2013 3:27 AM, Dan Harkins wrote:
>>    Dear Rene,
>>
>> On Mon, December 2, 2013 6:28 am, Rene Struik wrote:
>>> Dear colleagues:
>>>
>>> I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work
>>> that went into this draft, I have to concur with some other commenters
>>> (e.g., Doug Stebila, Bodo Moeller) that it is unclear what makes this
>>> protocol special compared to other contenders, both in terms of
>>> performance and detailed cryptanalysis. One glaring omission is
>>> detailed
>>> security evidence, which is currently lacking (cross-referencing some
>>> other standards that have specified the protocol does not by itself
>>> imply the protocol is therefore secure). I am kind of curious what
>>> technical advantages the "Dragonfly" protocol has over protocols that
>>> seem to have efficiency, detailed and crypto community reviewed
>>> evidence, such as, e.g., AugPAKE (which is another TLS-aimed draft) and
>>> others. So, if the TLS WG has considered a feature comparison, that
>>> would be good to share.
>>    dragonfly is a balanced PAKE kind of exchange and it has certain
>> advantages over augmented PAKE schemes like TLS-SRP (which, unlike
>> the augPAKE draft, is a published RFC that has been implemented).
>> Namely, the domain parameter set is not fixed with the password and
>> can be negotiated to provide security commensurate with that offered
>> by the rest of the cipher suite. And yes, the drawback of a balanced
>> PAKE scheme is that if the server is compromised and the password
>> file exposed then an attacker can impersonate users (although, in my
>> opinion, that is something of a dubious benefit since the server is
>> already compromised and this will be the least of your problems).
>>
>>    This has already been discussed in this thread by the way.

  Your curiosity on advantages dragonfly has over other exchanges is
not really a comment on the draft unless you are suggesting adding
such a section. Are you?

  Similarly, there is no statement of "specialness" in the draft so your
inability to determine its specialness is also not really anything to do
with something in the draft. Do you want a section on "specialness
considerations"? If so, can you point to any other similar types of
drafts/RFCs that have such a section?

>>> I would recommend to ask CFRG to carefully review the corresponding
>>> irtf-dragonfly-02 document (to my knowledge, there has been no LC and
>>> it
>>> is still a draft document there) and align the TLS document
>>> draft-ietf-tls-pwd-02 document with whatever comes out of that effort
>>> (currently, there are some security-relevant differences). This time
>>> window could also be used for firming up security rationale, thus
>>> aleviating concerns on that front.
>>    This suggestion has already been done.

  Indeed, this was done. The delta from -01 to -02 of the CFRG draft is
irrelevant to the draft under discussion here on this thread. There is no
LC on the IRTF draft but you can take that up with David and Kevin. There
are no changes possible to the draft under question regarding what the
CFRG is doing so I'm not sure how to resolve your comment.

>>> Two final comments:
>>> a) It is unclear why one should hard code in the draft that elliptic
>>> curves with co-factor h>1 would be ruled out. After all, this would
>>> make
>>> it much harder to extend the reach of the draft to prime curves with
>>> co-factor larger than one and to binary curves.
>>    You're right, it does prevent the use of binary curves and prime
>> curves
>> with a co-factor greater than one. That's the whole point. The
>> motivation
>> is to avoid walking through a patent mine field.

  We seem to disagree on this. I view binary curves and those with a
co-factor > 1 as problematic so the limitation is a feature.

  If you would like to make a case on why avoiding a patent minefield
is not a good thing to do we can try and gauge WG consensus on the
issue.

>>> b) The probabilistic nature of the "hunting and pecking" procedure may
>>> be a recipe for triggering implementation attacks. Wouldn't one be much
>>> better off removing dependency on non-deterministic password-to-point
>>> mappings (e.g., AugPAKE, Icart map, German BSI-password protocol)?
>>    The "hunting and pecking" procedure is deterministic otherwise there
>> would be no guarantee that each side arrived at the same element
>> given the same input.

  If this comment stands then explain what you'd like to see done to the
draft to address it. The technique is already deterministic and you seem to
want to remove non-determinism from it so I'm not sure what you're
looking for here.

  regards,

  Dan.

>>    regards,
>>
>>    Dan.
>>
>>> Best regards, Rene
>>>
>>> On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote:
>>>> This is the beginning of the working group last call for
>>>> draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
>>>> TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory
>>>> results.  The document needs particular attention paid to the
>>>> integration of this mechanism into the TLS protocol.   Please send
>>>> comments to the TLS list by December 2, 2013.
>>>>
>>>> - Joe
>>>> (For the TLS chairs)
>>>> _______________________________________________
>>>> 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
>>>
>>> _______________________________________________
>>> 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 trevp@trevp.net  Tue Dec  3 14:59:25 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3EE41ADF22 for ; Tue,  3 Dec 2013 14:59:25 -0800 (PST)
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 uEXO4qYAXWke for ; Tue,  3 Dec 2013 14:59:24 -0800 (PST)
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id C02871AE1A8 for ; Tue,  3 Dec 2013 14:59:23 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id hq4so7333586wib.8 for ; Tue, 03 Dec 2013 14:59:20 -0800 (PST)
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=y3GNd/q3IU8HmTOOLx5RrOYStJVw0bB4qVnGWczepPM=; b=J1s6Fw2Z8Njc9lkjfrRSzJV1oG3N8t9VbGjxyDrpKacmKiA4FNvzL3Ab2GUJ6qPoSA YqoNM7LAmTu3SsBjiV7NcbJqd5tBAHnOrH53EHxZ74D0ttpJFUREskpxXXyAwE0Zhj+G /7UuViNoZ8tsQF9e3+8gB4pTnrkDSV96ygbCLRJyLjvQmpQ65oM67CKn/ss3wwFxBFOt PN8SfC0wKEkKSBjKOPPzai04YF9SVJAdyEIIt3+gx1WqZw1droQCqEVgTR5gNbPwVU9w rwYrpl4ew3v+XIkGY0mUf6+yKR2rV5x8EmQnoW9K/Dx0PZExvs3TGH+OjjWi/Yt9pA6B rXng==
X-Gm-Message-State: ALoCoQk6mJ3sH+HJbe/x6TMF9JErO1YyybXtJI3jSl8JrAvUFelVDKy9N2f5Cwn7ImQf0XS49jkf
MIME-Version: 1.0
X-Received: by 10.180.108.162 with SMTP id hl2mr4584952wib.56.1386111560569; Tue, 03 Dec 2013 14:59:20 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Tue, 3 Dec 2013 14:59:20 -0800 (PST)
X-Originating-IP: [166.137.185.82]
In-Reply-To: <6b51bc68470b316cf6d38c7033c0d451.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> <6b51bc68470b316cf6d38c7033c0d451.squirrel@www.trepanning.net>
Date: Tue, 3 Dec 2013 14:59:20 -0800
Message-ID: 
From: Trevor Perrin 
To: Dan Harkins 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 03 Dec 2013 22:59:25 -0000

On Tue, Dec 3, 2013 at 12:27 AM, Dan Harkins  wrote:
>
>   Dear Rene,
>
> On Mon, December 2, 2013 6:28 am, Rene Struik wrote:
>> Dear colleagues:
>>
>> I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work
>> that went into this draft, I have to concur with some other commenters
>> (e.g., Doug Stebila, Bodo Moeller) that it is unclear what makes this
>> protocol special compared to other contenders, both in terms of
>> performance and detailed cryptanalysis. One glaring omission is detailed
>> security evidence, which is currently lacking (cross-referencing some
>> other standards that have specified the protocol does not by itself
>> imply the protocol is therefore secure). I am kind of curious what
>> technical advantages the "Dragonfly" protocol has over protocols that
>> seem to have efficiency, detailed and crypto community reviewed
>> evidence, such as, e.g., AugPAKE (which is another TLS-aimed draft) and
>> others. So, if the TLS WG has considered a feature comparison, that
>> would be good to share.
>
>   dragonfly is a balanced PAKE kind of exchange and it has certain
> advantages over augmented PAKE schemes like TLS-SRP

Wait, what?

"Augmented PAKE" is of course better than "Balanced PAKE", as it
allows the server to store non-usable credentials.

TLS already has an "Augmented PAKE" - TLS/SRP (RFC 5054) which is
implemented in OpenSSL and elsewhere.

It's not used on the web, or widely, as the TLS layer is generally the
wrong place for user authentication (e.g. leaks username, terminated
at front-end machines without access to user credentials, etc).

However, what little demand exists for a TLS PAKE seems like it's
being adequately served by TLS-SRP.

Why is the WG considering another PAKE with worse properties (non-augmented)?


Trevor

From dharkins@lounge.org  Tue Dec  3 16:12:22 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42D01ADD02 for ; Tue,  3 Dec 2013 16:12:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 vvcvdKzAr-_M for ; Tue,  3 Dec 2013 16:12:20 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id BFB6B1ADBCD for ; Tue,  3 Dec 2013 16:12:20 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7AE74A888012; Tue,  3 Dec 2013 16:12:17 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 3 Dec 2013 16:12:17 -0800 (PST)
Message-ID: <09dadea8236bf9e66d3e86277b4bd435.squirrel@www.trepanning.net>
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> <6b51bc68470b316cf6d38c7033c0d451.squirrel@www.trepanning.net> 
Date: Tue, 3 Dec 2013 16:12:17 -0800 (PST)
From: "Dan Harkins" 
To: "Trevor Perrin" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 00:12:23 -0000

On Tue, December 3, 2013 2:59 pm, Trevor Perrin wrote:
> On Tue, Dec 3, 2013 at 12:27 AM, Dan Harkins  wrote:
>>
>>   Dear Rene,
>>
>> On Mon, December 2, 2013 6:28 am, Rene Struik wrote:
>>> Dear colleagues:
>>>
>>> I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work
>>> that went into this draft, I have to concur with some other commenters
>>> (e.g., Doug Stebila, Bodo Moeller) that it is unclear what makes this
>>> protocol special compared to other contenders, both in terms of
>>> performance and detailed cryptanalysis. One glaring omission is
>>> detailed
>>> security evidence, which is currently lacking (cross-referencing some
>>> other standards that have specified the protocol does not by itself
>>> imply the protocol is therefore secure). I am kind of curious what
>>> technical advantages the "Dragonfly" protocol has over protocols that
>>> seem to have efficiency, detailed and crypto community reviewed
>>> evidence, such as, e.g., AugPAKE (which is another TLS-aimed draft) and
>>> others. So, if the TLS WG has considered a feature comparison, that
>>> would be good to share.
>>
>>   dragonfly is a balanced PAKE kind of exchange and it has certain
>> advantages over augmented PAKE schemes like TLS-SRP
>
> Wait, what?

  Yes, well good morning to you too!

> "Augmented PAKE" is of course better than "Balanced PAKE", as it
> allows the server to store non-usable credentials.

  This point was noted in the text you snipped in your response.

> TLS already has an "Augmented PAKE" - TLS/SRP (RFC 5054) which is
> implemented in OpenSSL and elsewhere.

  This was also mentioned in the text you snipped in your response.

> It's not used on the web, or widely, as the TLS layer is generally the
> wrong place for user authentication (e.g. leaks username, terminated
> at front-end machines without access to user credentials, etc).
>
> However, what little demand exists for a TLS PAKE seems like it's
> being adequately served by TLS-SRP.
>
> Why is the WG considering another PAKE with worse properties
> (non-augmented)?

  As has been discussed on the list, because it also has better
properties. And it has useful applications.

  A better question is, where have you been for the past 2 years?
You wait to question consideration of this draft not only after it's
been adopted as a working group item but also after WGLC has
closed on the draft!

  Dan.



From wtc@google.com  Tue Dec  3 18:28:34 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF2F1AE018 for ; Tue,  3 Dec 2013 18:28:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 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.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 Z1pfMZSME-uV for ; Tue,  3 Dec 2013 18:28:32 -0800 (PST)
Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6605B1ADF96 for ; Tue,  3 Dec 2013 18:28:32 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id hz11so10610589vcb.17 for ; Tue, 03 Dec 2013 18:28:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aMEi1XYGDHZhHBW9EigTLqabmPen+8cR7E/NoTvhsMs=; b=XQl89SElDnTEaH0U3tibipEvTMeW0m8nXvdg2wcunCPWp/lLmVXsDqpgW6oS9iTEQX 3b3EWkRB/u3+fACIy6I6yUuAsg4+PnXmD2NufhJrDytzvT99dGbPskWXywYw6/hr/yyG dWHv3p0KdknzUmGCBT+R3EFf4pX8wheUuV2PtyM3sRPS/Szj7gSpdPlhJ1AlF04zek5U 8BMZ/OCMdus9gs0hZyPlRFJuskR8IowybpBCfjIbJUMQJencJUWQXC5KmtBF4Bp1owHl 7XjdVyC5PmObrs3CT3WBChQVMpop/9Nt+cAfiwJW56HBRW6Xb0X2fIvnj4L8KNBs1Xs8 F8Ng==
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=aMEi1XYGDHZhHBW9EigTLqabmPen+8cR7E/NoTvhsMs=; b=Xz5iYaLhMvM2Mcb+BPoEPUpwxJ8B9SDQewuMAxiBQ25OZapz3wsHTlcmrc9mAnZy5m pJIxvGakWS2KvsdiSpDVX1fbBbWOJwclCpoI96M0jyt5TX6l8EBLeLIVHnf6zNZEZRAx oDyJ4mgGUrd5TPCbfM4xW7CEnubFZZAgGKijkBkfuu4f1EmZERSusFwTHHcUmAZXycHD e10nI6lRn4lMNJCR8or2+W5QkYiZ1svaKlwXs1jaXGzxA2LnEFxX59ciAfKGx26D70wX AaferzYiLOQ/z7YwjiqAdhTqNdBgOjuO9KaOWHkRULgzjDKVnS1HXgj8I0vvLqQb7kJj /mmw==
X-Gm-Message-State: ALoCoQnVQkEcFwkkZXeMXKBPSBWaoFad7JY9pXUl13OTOTfAGdlNmibO6Jkaxep43qSLdm0AtPwpH5GHE7mEgGDkl4ZK8Rz/5EHKcAlAOFapePbT1bCBy9hckzonPHxyHYsaAbrHNdLw7v2gRAJVRw339EI7beivwlOlhj+rWLy0CPyV/5omHxhk+mH5rk5eRz1INqr/7tp6
MIME-Version: 1.0
X-Received: by 10.52.50.177 with SMTP id d17mr6814124vdo.23.1386124109308; Tue, 03 Dec 2013 18:28:29 -0800 (PST)
Received: by 10.52.167.10 with HTTP; Tue, 3 Dec 2013 18:28:29 -0800 (PST)
In-Reply-To: 
References:        
Date: Tue, 3 Dec 2013 18:28:29 -0800
Message-ID: 
From: Wan-Teh Chang 
To: Bodo Moeller , Adam Langley 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 02:28:34 -0000

On Thu, Nov 28, 2013 at 4:21 AM, Bodo Moeller  wrote:
> Everyone,
>
> the new I-D for TLS_FALLBACK_SCSV is now at
> http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01.

Bodo, Adam,

I read your -01 draft while reviewing your OpenSSL and NSS patches for
TLS_FALLBACK_SCSV.

I have some comments.

1. Why don't you also specify a TLS extension, which can be used when
we fall back to a lesser TLS version (but not SSL 3.0)?

I assume specifying only a SCSV is for simplicity.

2. I don't understand why you want the server to report an
inappropriate fallback only if the client drops below the server's
highest supported version.

This means an inappropriate fallback is not always reported to the
client, or it is reported to the client only after multiple fallbacks.

For example, suppose the server supports TLS 1.1 and the client
supports TLS 1.2.

If a middle box blocks only TLS 1.2 ServerHello and injects a TCP
Reset (this middle box behavior was observed, not hypothetical), the
client will retry with a TLS 1.1 ClientHello with the fallback SCSV,
but the server will then finish the handshake successfully.

On the other hand, if a middle box blocks both TLS 1.2 and TLS 1.1
ServerHellos and injects a TCP Reset, the client will retry twice,
first with a TLS 1.1 ClientHello and then with a TLS 1.0 ClientHello.
Although the ClientHellos in both retries have the fallback SCSV, the
server will only respond with an inappropriate_fallback alert to the
second retry.

I think the draft should explain the rationale for this less strict
server behavior.

3. In the Security Considerations section, we have:

   However, it is particularly strongly recommended to send
   TLS_FALLBACK_SCSV when downgrading to SSL 3.0 as the CBC cipher
   suites in SSL 3.0 have weaknesses that cannot be addressed by
   implementation workarounds like the remaining weaknesses in later
   (TLS) protocol versions.

It would be nice to name the weaknesses and workarounds explicitly.
The implicit IV weakness of TLS 1.0 and SSL 3.0 can be worked around
by record splitting, so I assume that's not the weakness you're
referring to. Are you referring to the CBC padding timing attacks?

Also, it seems that the main problem with downgrading to SSL 3.0 is
the loss of features and cipher suites that require TLS extensions,
such as Server Name Indication and ECC cipher suites. You already
mentioned that in the Introduction section. If the loss of these
features and cipher suites degrades security, it should be mentioned
in the Security Considerations section as well.

Finally, the fallback to TLS 1.1 loses AEAD ciphers, and the fallback
to TLS 1.0 loses the explicit IV for CBC block ciphers (although the
record splitting workaround is effective). Perhaps these should also
be mentioned.

Wan-Teh Chang

From trevp@trevp.net  Tue Dec  3 18:58:24 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B2E1ADFF5 for ; Tue,  3 Dec 2013 18:58:23 -0800 (PST)
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 ciaLlERETiIN for ; Tue,  3 Dec 2013 18:58:22 -0800 (PST)
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id ED8B11ADFAD for ; Tue,  3 Dec 2013 18:58:21 -0800 (PST)
Received: by mail-wg0-f47.google.com with SMTP id n12so13144934wgh.2 for ; Tue, 03 Dec 2013 18:58:18 -0800 (PST)
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=2jhAM4gtCXjl1tclbo07AIgq+ofSpapET2XTFwE1XuM=; b=fhgycXfxalv4Axj9Ext6TaJUvbVSEnxZweMYXzgr4B2PddzURIjsRcl6sQskFE3Jte c8XeTQfEVYwWvWtZt2C1WxOo9ED2b2+bpEqyHopjsjOlnFSH5cuLcR+fvTGZ+WBIbGna cSGYQLtan93cqFlknzfp0ZwLmSkB9wairetWQcgONIAqU6r6Z/EJ2zWbwBhy0fvozm2w GFPyKioA2TU20PDrdk5uubDHKgjxKd/DDzzxrsY8zC7AR+rifp2fLZXUttfWCf8ePwZv JKptk0BR3MtAmrV+yT4YwMzQKTFrADfVfdgnzG9/hko94fW2rjBtC9+bSwxzdPMnLbCP 6G9A==
X-Gm-Message-State: ALoCoQllFX7VNtRBu7JLFUBLB0q4xWLIibq8JxvWL3MoX/Bojf5jV/2BGSlRu3Z4yN7/pmDhWbNg
MIME-Version: 1.0
X-Received: by 10.194.142.142 with SMTP id rw14mr60028wjb.87.1386125898505; Tue, 03 Dec 2013 18:58:18 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Tue, 3 Dec 2013 18:58:18 -0800 (PST)
X-Originating-IP: [166.137.185.82]
In-Reply-To: <09dadea8236bf9e66d3e86277b4bd435.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> <6b51bc68470b316cf6d38c7033c0d451.squirrel@www.trepanning.net>  <09dadea8236bf9e66d3e86277b4bd435.squirrel@www.trepanning.net>
Date: Tue, 3 Dec 2013 18:58:18 -0800
Message-ID: 
From: Trevor Perrin 
To: Dan Harkins 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 02:58:24 -0000

On Tue, Dec 3, 2013 at 4:12 PM, Dan Harkins  wrote:
>
>>
>> Why is the WG considering another PAKE with worse properties
>> (non-augmented)?
>
>   As has been discussed on the list, because it also has better
> properties.

What I can find you claiming is [1]:
"""
What=92s wrong with SRP? Nothing, but...
 - Nice to have EC support
 - Finite cyclic group is not fixed for each user
"""

I can't see how it matters that an SRP user's password has a fixed
group.  And I don't think EC alone justifies this, given that:
 - it has weaker security properties than SRP (non-augmented)
 - it has an ad-hoc design still being subject to attacks (see Bodo's point=
)
 - TLS/SRP is already deployed and in use by the few people who care
about TLS PAKE


>   A better question is, where have you been for the past 2 years?

Reading this list.  The feedback has been almost entirely negative
since you first proposed it [2].  I haven't had much to add.

Trevor

[1] http://www.ietf.org/proceedings/83/slides/slides-83-tls-2.pdf
[2] http://www.ietf.org/mail-archive/web/tls/current/msg08208.html

From trevp@trevp.net  Tue Dec  3 19:04:37 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B321ADFF5 for ; Tue,  3 Dec 2013 19:04:37 -0800 (PST)
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 BXpEmMuhgwEC for ; Tue,  3 Dec 2013 19:04:35 -0800 (PST)
Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7D10C1ADFAD for ; Tue,  3 Dec 2013 19:04:35 -0800 (PST)
Received: by mail-wg0-f49.google.com with SMTP id x12so14174594wgg.28 for ; Tue, 03 Dec 2013 19:04:32 -0800 (PST)
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=l/EO8gmWbwMCOD4ZKi8RUqj9HqW9+8M08jKLOwnFZu4=; b=k7w05nuUo3JO53KpHMrdBHrY26FQPHCA0DNC9ojWHg9/zw2bRB92biHrmFLlt2CHrs /XVoEsflUE7kGiFOJ+gr5jwgt42U3IOzJ2owqAmsu8dPc7YGoW6EiAYwQdCt3mRMAPif Rm510LRTNmx3VIW0XKINnZBULdMC7/5Q/uvhmaBup6S/hxiRl0vkuO0/wjD58GzGr+4D b8CuTCpTnhOyKe0suqO25Giy/3FkIKI4sl8vQ9aA1fV0pYPNc3mTwKg9JV7MhFb69jx9 phhckeNjZb4TilCFn0jTaUFLMSZ0osVknjrWkMkCqnZnS+AHD9niZew52HAHtBybF9JV F27A==
X-Gm-Message-State: ALoCoQl9KqdvpbfYvsCl86yW2nap/76IUNp8lIaJ7f5IG2Z+W0mDKs7BzBBZRKeTIkp3P5FYAcYj
MIME-Version: 1.0
X-Received: by 10.180.11.169 with SMTP id r9mr5202522wib.26.1386126272249; Tue, 03 Dec 2013 19:04:32 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Tue, 3 Dec 2013 19:04:32 -0800 (PST)
X-Originating-IP: [166.137.185.82]
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> <6b51bc68470b316cf6d38c7033c0d451.squirrel@www.trepanning.net>  <09dadea8236bf9e66d3e86277b4bd435.squirrel@www.trepanning.net> 
Date: Tue, 3 Dec 2013 19:04:32 -0800
Message-ID: 
From: Trevor Perrin 
To: Dan Harkins 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 03:04:37 -0000

On Tue, Dec 3, 2013 at 6:58 PM, Trevor Perrin  wrote:
> On Tue, Dec 3, 2013 at 4:12 PM, Dan Harkins  wrote:
>>
>>   A better question is, where have you been for the past 2 years?
>
> Reading this list.  The feedback has been almost entirely negative
> since you first proposed it [2].  I haven't had much to add.
>
> Trevor
>
> [1] http://www.ietf.org/proceedings/83/slides/slides-83-tls-2.pdf

Fixing the reference:
[2]  http://www.ietf.org/mail-archive/web/tls/current/msg08162.html


Trevor

From maray@microsoft.com  Tue Dec  3 19:14:06 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC1B1ADFFD for ; Tue,  3 Dec 2013 19:14:06 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ve2gt_yd2E3y for ; Tue,  3 Dec 2013 19:14:03 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) by ietfa.amsl.com (Postfix) with ESMTP id C30A01ADFF5 for ; Tue,  3 Dec 2013 19:14:02 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB075.namprd03.prod.outlook.com (10.255.241.155) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 4 Dec 2013 03:13:57 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.159]) with mapi id 15.00.0820.005; Wed, 4 Dec 2013 03:13:57 +0000
From: Marsh Ray 
To: Watson Ladd , "Joseph Salowey (jsalowey)" 
Thread-Topic: [TLS] TLS Charter Revision
Thread-Index: AQHO75QH12xj16hlv0SmAgrMfgWOIZpB1QcAgAF+I3A=
Date: Wed, 4 Dec 2013 03:13:57 +0000
Message-ID: <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.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:80e0:ed43::3]
x-forefront-prvs: 0050CEFE70
x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(65816001)(15975445006)(80976001)(49866001)(77982001)(87266001)(33646001)(19580405001)(15202345003)(85306002)(83072001)(83322001)(53806001)(80022001)(81542001)(56816005)(90146001)(85852002)(63696002)(54356001)(19580395003)(47446002)(81342001)(81816001)(74366001)(56776001)(31966008)(47976001)(46102001)(59766001)(76482001)(81686001)(74316001)(77096001)(76786001)(74706001)(74662001)(76796001)(87936001)(51856001)(69226001)(74502001)(54316002)(2656002)(47736001)(74876001)(79102001)(4396001)(76576001)(50986001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB075; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::3; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "" 
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 03:14:06 -0000

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Watson Ladd

> I strenuously object to the proposed rechartering as it now stands.
> First, I do not have confidence in this WG and its chair to deliver a sec=
ure protocol to the
> IESG. They did not the previous 3 times, and I do not want to give them a=
 4th shot
> without some guarantee of the quality.

> Secondly, the proposed recharting has made certain technical decisions re=
lated to
> the protocol without due discussion, in particular the list of goals impl=
ies that we
> keep the stupidity of multiple ciphersuites and extensions galore around.

SSL/TLS has had some issues over the last 20 years, but I can't think of an=
y serious ones *caused* by the multiplicity of ciphersuites and extensions.=
 To the contrary, the version negotiation, cipher suite, and extension mech=
anisms have been invaluable in rapidly deploying fixes when cracks have app=
eared in the other parts.

> Thirdly, the experience of TLS 1.2 teaches us that no matter how compatib=
le a
> protocol upgrade is, it will not happen, and so one need not keep compati=
bility.

That must be why SSLv2 has 99% server market share and TLS has only 20%. Oh=
 wait, I got that backwards. https://www.trustworthyinternet.org/ssl-pulse/
So uhh..."baloney".

Looks like the latest version of Centos and its upstream "major North Ameri=
can Linux vendor"
Made this change "OpenSSL and NSS now support TLS 1.1 and 1.2."
http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.5

Microsoft clients and servers have supported it for years now but it has be=
en off by default.

Oh looky... 83.9% of sites have even added support for the RFC 5746 Renegot=
iation Indication security patch in just the last 3-4 years, whereas only 7=
4.3% of servers have disabled SSLv2. I dunno, could have something to do wi=
th the fact that the extension mechanism allows adoption without breaking e=
xisting clients and servers.

> Fourthly, item 3 is not strong enough: AtE needs to die a fiery death and=
 nothing short of killing RC4 will address its shortcomings.

I agree that AtE was a mistake and needs to go, but what would killing RC4 =
do to "address its shortcomings"?

> I propose the following charter instead.
> "To create a protocol establishing a secure encrypted and authenticated c=
hannel in the
> standard model between parties A and B, supporting the following authenti=
cation methods:
> -One-way authentication with the PKI
> -Two-way authentication with the PKI
> -Two-way authentication with a shared low-entropy secret -One side authen=
ticated with the PKI, and the other with a shared low-entropy secret.
> Said protocol will function over UDP and TCP with a minimum of handshakes=
, complexity, and options, and will have a formal security proof."

Gee you make it sound so easy.

I think we should also consider forward secrecy to be a required and essent=
ial security property these days.

Also, how about some security for anonymous connections too? And resistance=
 to traffic analysis and fingerprinting. And privacy of the endpoints' iden=
tities. And not becoming a browser evercookie. And not enabling any new for=
ms of server DoS attacks. And so on.

- Marsh


From watsonbladd@gmail.com  Tue Dec  3 20:08:17 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7205C1ADF80 for ; Tue,  3 Dec 2013 20:08:17 -0800 (PST)
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 PctfZvtKiYP9 for ; Tue,  3 Dec 2013 20:08:14 -0800 (PST)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 807831ADF0E for ; Tue,  3 Dec 2013 20:08:14 -0800 (PST)
Received: by mail-wi0-f182.google.com with SMTP id en1so7553952wid.15 for ; Tue, 03 Dec 2013 20:08:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UuLrrMbKrWuLl7XQMqdaPAgjBYorkLIN7jKBfR6K+Tc=; b=bFZPKPDzFRRjgYLbEWQYtT+Po7AoNZ0IIK8x81oIeK/KuIemfooFKWyjKrTjvfFLZe oU52GBH6LXDgf6rPvCpiu62t6PrRwNySQYUKnzNHLAEpS7GrVCvRy28WzRW7FBO36UnJ DL1nEb3xMi29xIDiZPkr/R6NG0bwb1PoEvFs4N0vrzpaZruArh6dNJXHJzV2we/NlHAa mmbsViNuQA14ifUGEVY60bUvxGjM4tiocyZs15yo9yJfeoDl+DxUEyTUnBtGhcs1kWB7 Zn9K1LSgkCdivUjeW19vHvz5UP0yxPcWImfXXbqF1/So7bYZvwilrCYvDQ327t6xUzun JCpw==
MIME-Version: 1.0
X-Received: by 10.194.85.75 with SMTP id f11mr10285404wjz.14.1386130091174; Tue, 03 Dec 2013 20:08:11 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Tue, 3 Dec 2013 20:08:11 -0800 (PST)
In-Reply-To: <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>  <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com>
Date: Tue, 3 Dec 2013 20:08:11 -0800
Message-ID: 
From: Watson Ladd 
To: Marsh Ray 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" 
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 04:08:17 -0000

On Tue, Dec 3, 2013 at 7:13 PM, Marsh Ray  wrote:
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Watson Ladd
>
>> I strenuously object to the proposed rechartering as it now stands.
>> First, I do not have confidence in this WG and its chair to deliver a se=
cure protocol to the
>> IESG. They did not the previous 3 times, and I do not want to give them =
a 4th shot
>> without some guarantee of the quality.
>
>> Secondly, the proposed recharting has made certain technical decisions r=
elated to
>> the protocol without due discussion, in particular the list of goals imp=
lies that we
>> keep the stupidity of multiple ciphersuites and extensions galore around=
.
>
> SSL/TLS has had some issues over the last 20 years, but I can't think of =
any serious ones *caused* by the multiplicity of ciphersuites and extension=
s. To the contrary, the version negotiation, cipher suite, and extension me=
chanisms have been invaluable in rapidly deploying fixes when cracks have a=
ppeared in the other parts.
Other than letting people shoot themselves in the foot by making
insecure choices and limiting the number of compatible
implementations, as well as confounding security analysis?
>
>> Thirdly, the experience of TLS 1.2 teaches us that no matter how compati=
ble a
>> protocol upgrade is, it will not happen, and so one need not keep compat=
ibility.
>
> That must be why SSLv2 has 99% server market share and TLS has only 20%. =
Oh wait, I got that backwards. https://www.trustworthyinternet.org/ssl-puls=
e/
> So uhh..."baloney".
>
Look at TLS 1.2 vs TLS 1.0. Active attacks exist that are only fixed
by TLS 1.2. That's also server side, not client side, so it's only
part of the full picture. And it's been 14 years since TLS 1.0 came
out. Major US financial institutions, responsible for trillions of
assets, deploy TLS in configurations that are insecure.
> Looks like the latest version of Centos and its upstream "major North Ame=
rican Linux vendor"
> Made this change "OpenSSL and NSS now support TLS 1.1 and 1.2."
> http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.5
>
> Microsoft clients and servers have supported it for years now but it has =
been off by default.
A functioning upgrade path protects the upgraded. That it's been off
by default shows just how bad the upgrade picture is.
>
> Oh looky... 83.9% of sites have even added support for the RFC 5746 Reneg=
otiation Indication security patch in just the last 3-4 years, whereas only=
 74.3% of servers have disabled SSLv2. I dunno, could have something to do =
with the fact that the extension mechanism allows adoption without breaking=
 existing clients and servers.
If your browser is negotiating a broken protocol it is broken. Keeping
you using it is doing no one any favours.
>
>> Fourthly, item 3 is not strong enough: AtE needs to die a fiery death an=
d nothing short of killing RC4 will address its shortcomings.
>
> I agree that AtE was a mistake and needs to go, but what would killing RC=
4 do to "address its shortcomings"?
That "and" was not subordinating/the "its" goes with RC4 not AtE.
>
>> I propose the following charter instead.
>> "To create a protocol establishing a secure encrypted and authenticated =
channel in the
>> standard model between parties A and B, supporting the following authent=
ication methods:
>> -One-way authentication with the PKI
>> -Two-way authentication with the PKI
>> -Two-way authentication with a shared low-entropy secret -One side authe=
nticated with the PKI, and the other with a shared low-entropy secret.
>> Said protocol will function over UDP and TCP with a minimum of handshake=
s, complexity, and options, and will have a formal security proof."
>
> Gee you make it sound so easy.
What part do you think is hard? We've known how to do all of this
since basically forever in cryptography terms, except the formal proof
part, but
that's automatic now. CurveCP has all of this working except the
shared low-entropy secret part.
>
> I think we should also consider forward secrecy to be a required and esse=
ntial security property these days.
>
> Also, how about some security for anonymous connections too? And resistan=
ce to traffic analysis and fingerprinting. And privacy of the endpoints' id=
entities. And not becoming a browser evercookie. And not enabling any new f=
orms of server DoS attacks. And so on.
>
> - Marsh
>



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

From trevp@trevp.net  Tue Dec  3 21:56:33 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7A71AE1D3 for ; Tue,  3 Dec 2013 21:56:33 -0800 (PST)
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 Xr7ESdZz7yLe for ; Tue,  3 Dec 2013 21:56:31 -0800 (PST)
Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 55B091AE1CC for ; Tue,  3 Dec 2013 21:56:31 -0800 (PST)
Received: by mail-wg0-f42.google.com with SMTP id a1so6517384wgh.5 for ; Tue, 03 Dec 2013 21:56:27 -0800 (PST)
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=QJUMe1cexidMyWccb5yw0elO2VXmjHD0NBTl+Wn++Gc=; b=iVAMT3l7un/R4iZQV7pSGmwn9kZT6dG7esSsae0r/3SLvcLIMyU2l9ta8c4LI5Wsul qcUUBKhmVd86E/SUcEsTnyQPk+/ohIOSfnmL1n9lITPbzVjMbebHIwKW0k1wvGy3Cyrs /JTgjyUe2VwxCdsZHsKx7Sth6GdxQJlxfsLk9kjro7ZmGpYd5epPPiU5o8GDWetyGYyo EN59Hx/UL6U7NgkHWDA9nt3Fr9UAcgJMQMJJ7YaSwPLKgkJHnIMaBwMsWedrVvKO+yog xm3JF/06wpjDOVYcl57x1PObR6C00qna0yAZiiPUKczvlP6J9kYfQro75voncXahDznq XM8w==
X-Gm-Message-State: ALoCoQn5NRyaUiEoHf9bnH2WBGBX6QbzRuDvlEs4OVWqZQWcaSgFzcSBYDJOw8JWE9Ht+1S9nCt6
MIME-Version: 1.0
X-Received: by 10.180.11.169 with SMTP id r9mr5612494wib.26.1386136587870; Tue, 03 Dec 2013 21:56:27 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Tue, 3 Dec 2013 21:56:27 -0800 (PST)
X-Originating-IP: [64.134.226.64]
In-Reply-To: 
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>  <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> 
Date: Tue, 3 Dec 2013 21:56:27 -0800
Message-ID: 
From: Trevor Perrin 
To: Watson Ladd 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" 
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 05:56:33 -0000

On Tue, Dec 3, 2013 at 8:08 PM, Watson Ladd  wrote:
> On Tue, Dec 3, 2013 at 7:13 PM, Marsh Ray  wrote:
>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Watson Ladd
>>
>>> I propose the following charter instead.
>>> "To create a protocol establishing a secure encrypted and authenticated channel in the
>>> standard model between parties A and B, supporting the following authentication methods:
>>> -One-way authentication with the PKI
>>> -Two-way authentication with the PKI
>>> -Two-way authentication with a shared low-entropy secret -One side authenticated with the PKI, and the other with a shared low-entropy secret.
>>> Said protocol will function over UDP and TCP with a minimum of handshakes, complexity, and options, and will have a formal security proof."
>>
>> Gee you make it sound so easy.
> What part do you think is hard? We've known how to do all of this
> since basically forever in cryptography terms, except the formal proof
> part, but
> that's automatic now. CurveCP has all of this working

It doesn't, actually.  CurveCP has some security flaws [1], no formal
proof, no PKI support, and lacks the low-round-trip properties that
are TLS 1.3 goals.

Key agreement remains a complex topic even in academia.  Trying to
balance low round-trips, computational efficiency,
handshake-data-hiding, implementation complexity,
backwards-compatibility, extensibility, IPR, etc. involves difficult
tradeoffs.

Anyways, I prefer Joseph's charter, as it identifies specific focuses
for improvement (round-trips, handshake-data-hiding), whereas yours is
quite vague ("minimum of handshakes, complexity, and options").


Trevor

[1] http://codesinchaos.wordpress.com/2012/09/09/curvecp-1/

From nmav@redhat.com  Wed Dec  4 00:11:47 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05F31AE080 for ; Wed,  4 Dec 2013 00:11:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 j4JItdMOjdJQ for ; Wed,  4 Dec 2013 00:11:42 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED731AE070 for ; Wed,  4 Dec 2013 00:11:42 -0800 (PST)
Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rB48BcIw019906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Dec 2013 03:11:38 -0500
Received: from [10.10.62.181] (vpn-62-181.rdu2.redhat.com [10.10.62.181]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rB48BaQa031199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Dec 2013 03:11:37 -0500
Message-ID: <1386144695.2047.30.camel@aspire.lan>
From: Nikos Mavrogiannopoulos 
To: "Paterson, Kenny" 
Date: Wed, 04 Dec 2013 09:11:35 +0100
In-Reply-To: 
References: 
Organization: Red Hat
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.25
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 08:11:47 -0000

On Sat, 2013-11-30 at 17:29 +0000, Paterson, Kenny wrote:

> >Proven to be secure doesn't mean that attacks don't exist. The TLS
> >padding scheme was proven to be secure prior to be broken; ironically by
> >the same person who made the proof. Attacks work by playing outside the
> >requirements of the proof.
> 
> I assume here that you're referring to my "Tag size matters" paper with
> Ristenpart and Shrimpton, and then to the Lucky 13 paper here. OK, with
> some of my TLS credentials established for those who don't know me, here
> are the key points that I take away from the TLS proof (from that paper)
> versus the Lucky 13 attack:
> 
> The proof for MAC-then-Pad-then-Encrypt in TLS was extremely delicate and
> difficult to produce. Indeed, in generating it, we came up with another
> new attack on "TLS with short MACs" that excludes certain parameters from
> ever being secure. We then had to make an assumption for the proof to go
> through: that the decryption process does not leak the source of
> decryption failure (sanity check failure, bad pad, or bad MAC), or any of
> the timing involved in decryption.

Hello Kenny,
 Indeed, this is the paper I was referring to. Note however, that my
main point was not about any issue with the proof instead, but how
crypto proofs should be interpreted by non-hardcore-crypto experts. As
we are now, a proof in a cryptography field is not equivalent to a
proof, for example, in the language of mathematics, which is typically
accepted as a universal truth. 

> What the Lucky 13 attack showed is that achieving this "uniformity of
> errors" is very difficult for TLS's MAC-then-Pad-then-Encrypt construction.

Indeed, and the paper contributes a lot to our knowledge of the AtE
mode.

> And this is why MAC-then-Encrypt - and its real world variants - are being
> given such a hard time on this list by some, including me: our bitter
> experience is that implementing it securely is just much too hard. Witness
> Adam Langley's 500 line patch for OpenSSL and NSS to get this (finally)
> right. (Side note - Adam deserves credit for independently discovering the
> same attack vector that we used in Lucky 13.)
> To add a bit more detail: during the Lucky 13 disclosure process, I worked
> with many vendors to help them get their patches ready. Very few of them
> were actually able to completely eliminate timing side channels completely
> in their implementations, and all that I know of (except for Adam) settled
> for a "good enough" approach. Of course, that pragmatic approach is quite
> justifiable. But it may still leave open small windows of opportunity for
> future attack.

That's why I don't like this kind of fixes (having 500 or 1000 lines to
remove the CBC padding is unacceptable to me). Thus I find it natural
for an implementer to avoid such a fix, as he may accidentally introduce
more bugs than the one it solves.  This is the reason I would like to
see a proper fix in the protocol.

> Bottom line: none of the many issues that MAC-then-Pad-then-Encrypt has
> had in TLS should *ever* arise for Encrypt-then-MAC, unless the
> implementer was extremely ill-educated.

Indeed, but I believe the same point applies for AtE if AtE is seen as
Pad-then-MAC-then-Encrypt (thanks to your attacks and papers, this is
the only reasonable interpretation of AtE today).

> To me, the perceived dangers of exposing the MAC - dangers which neither I
> (nor any serious cryptographer I know) accept as being real - are far
> outweighed by the simplicity and robustness provided by an
> Encrypt-then-MAC approach.

I agree that if TLS would be redesigned today, that could be a very good
point. However, this is not the case. The issue at hand is a fix in the
CBC ciphersuites and I find it quite drastic change (*) to switch the
order of encryption and authentication in all ciphersuites just because
of an issue in the CBC ones. That's why I'd prefer a simple fix for the
issue at hand that is _known_ to be as secure as EtA for the ciphers we
use.

(*). drastic but acceptable for me though - see my previous posts.

> >Nevertheless, there is much more recent work on EtA vs AtE, that
> >actually proves AtE secure (not "generically" as you pose, you just need
> >a decent cipher). You may check "The order of encryption and
> >authentication for protecting communications (or: How secure is SSL?)".
> >There are even newer papers than that, it is just this that came to
> >mind.
> 
> This is too simplistic an interpretation of that paper by Hugo Krawczyk,
> I'm afraid. It's an excellent piece of work, and quite ahead of its time
> in trying to apply provable security techniques to a real protocol. But it
> has two major shortcomings if you try to apply it to CBC-mode encryption
> as used in TLS:
> 1. It does not consider TLS padding whatsoever - but instead assumes data
> is all block-aligned. As soon as you introduce padding in-between the MAC
> and the encryption, i.e. as in TLS's actual construction, you run into
> lots of trouble - Vaudenay, Bodo Moeller's observations, Lucky 13 and all.

This is true, but it is part of my argumentation as I consider AtE to be
pad-then-MAC-then-encrypt, can be seen as no padding whatsoever, the AtE
proof applies directly.

> 2. It assumes the MAC output size is the same as the block cipher's block
> size.

That I hadn't notice, and if it is not fixable, it is indeed a strong
counter-argument against pad-mac-then-encrypt.

> On the plus side, and perhaps this is what you were referring to, Hugo's
> analysis works just fine for stream-cipher based ciphersuites (as long as
> the stream cipher is good - so not RC4 then!). The Asiacrypt 2011 paper
> can be seen as extending his analysis to handle the actual construction
> used in TLS's CBC-mode ciphersuites, but with the important, necessary,
> and difficult-to-achieve proviso concerning uniformity of errors.

So as I understand your proof fixes the point (2), that you mentioned
above?

> But, at the risk of repeating myself, I very much prefer the simplicity
> and robustness of an Encrypt-then-MAC construction.
> Of course, this is just another opinion, like many others that have been
> expressed on this list recently, and I cannot hope it will be the last
> word on the subject. But I can hope that it's accepted as an opinion born
> from significant experience in analysing TLS security, from a variety of
> perspectives (theoretical, implementation, attacks).

I believe your opinion is greatly appreciated on this list (and of
course by me), so thanks for taking the time of expressing it. It is
nice to discuss with solid arguments.

best regards,
Nikos



From nmav@redhat.com  Wed Dec  4 01:14:24 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236A31AE211 for ; Wed,  4 Dec 2013 01:14:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 0yUMHoQ2-JAc for ; Wed,  4 Dec 2013 01:14:22 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7C94B1AE0D9 for ; Wed,  4 Dec 2013 01:14:22 -0800 (PST)
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 rB49ECWS032335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Dec 2013 04:14:12 -0500
Received: from [10.10.62.181] (vpn-62-181.rdu2.redhat.com [10.10.62.181]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rB49EAog030629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Dec 2013 04:14:11 -0500
Message-ID: <1386148449.2047.57.camel@aspire.lan>
From: Nikos Mavrogiannopoulos 
To: "Joseph Salowey (jsalowey)" 
Date: Wed, 04 Dec 2013 10:14:09 +0100
In-Reply-To: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>
Organization: Red Hat
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
Cc: "" 
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 09:14:24 -0000

On Mon, 2013-12-02 at 19:23 +0000, Joseph Salowey (jsalowey) wrote:

> o Develop a mode that encrypts as much of the handshake as
> is possible to reduce the amount of observable data to
> both passive and active attackers.

I'd phrase that differently. I believe what we want to achieve is to
protect the identity of the participants, as well as the purpose of
connection (service), from passive (and if possible) from active
attackers. That gives a purpose to the goal (encrypting stuff is good,
but doesn't explain why we need that).

> o Reevaluate record payload protection cryptographic
>  mechanisms and algorithms to address known weaknesses
>  in RC4 and the CBC block cipher modes.

I think this contains two completely different issues. I'd split it into
* Replace RC4 with a known to be secure stream cipher
* Fix the known weaknesses in the CBC block cipher mode.

(I'm not so strong about the splitting, but given the existing work on
the topic the word Re-evaluate seems to be suggesting a further delay.
There is nothing to evaluate in the RC4 issue - it is broken, and we
already have more than one suggested solutions for the CBC issue)

Moreover this goal is not reflected in the milestones. Given the work
that is already there I'd expect to have these two points completed not
later than the beginning of 2014.

Except with the two points above, I agree with the charter revision.

regards,
Nikos



From Kenny.Paterson@rhul.ac.uk  Wed Dec  4 01:21:00 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD1F1ADFD0 for ; Wed,  4 Dec 2013 01:21:00 -0800 (PST)
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 Ni-RW_y15jKw for ; Wed,  4 Dec 2013 01:20:58 -0800 (PST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id C879A1AE21C for ; Wed,  4 Dec 2013 01:20:57 -0800 (PST)
Received: from mail84-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 09:20:54 +0000
Received: from mail84-va3 (localhost [127.0.0.1])	by mail84-va3-R.bigfish.com (Postfix) with ESMTP id 8DC8E4E01B3; Wed,  4 Dec 2013 09:20:54 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.149; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0311HT005.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -7
X-BigFish: PS-7(zzbb2dI98dI936eI1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h17326ah8275bh1de097h186068h5eeeKz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h1155h)
Received-SPF: pass (mail84-va3: domain of rhul.ac.uk designates 157.56.249.149 as permitted sender) client-ip=157.56.249.149; envelope-from=Kenny.Paterson@rhul.ac.uk; helo=AM2PRD0311HT005.eurprd03.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(243025003)(51704005)(199002)(189002)(24454002)(377424004)(479174003)(15202345003)(65816001)(80022001)(66066001)(74706001)(81342001)(77982001)(59766001)(74366001)(56776001)(69226001)(76796001)(63696002)(90146001)(54316002)(81542001)(76786001)(56816005)(79102001)(85852002)(53806001)(54356001)(46102001)(51856001)(87266001)(81686001)(76482001)(83322001)(19580405001)(19580395003)(83506001)(31966008)(76176001)(85306002)(15975445006)(80976001)(47446002)(74662001)(74482001)(74502001)(49866001)(47736001)(4396001)(36756003)(47976001)(50986001)(74876001)(2656002)(87936001)(81816001)(83072001); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR03MB382; H:DBXPR03MB383.eurprd03.prod.outlook.com; CLIP:80.42.211.100; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail84-va3 (localhost.localdomain [127.0.0.1]) by mail84-va3 (MessageSwitch) id 1386148852643338_21999; Wed,  4 Dec 2013 09:20:52 +0000 (UTC)
Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.247])	by mail84-va3.bigfish.com (Postfix) with ESMTP id 8DB712C00A5;	Wed,  4 Dec 2013 09:20:52 +0000 (UTC)
Received: from AM2PRD0311HT005.eurprd03.prod.outlook.com (157.56.249.149) by VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 09:20:52 +0000
Received: from DBXPR03MB382.eurprd03.prod.outlook.com (10.141.10.12) by AM2PRD0311HT005.eurprd03.prod.outlook.com (10.255.162.40) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 4 Dec 2013 09:20:44 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB382.eurprd03.prod.outlook.com (10.141.10.12) with Microsoft SMTP Server (TLS) id 15.0.837.10; Wed, 4 Dec 2013 09:20:42 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.0837.004; Wed, 4 Dec 2013 09:20:42 +0000
From: "Paterson, Kenny" 
To: Nikos Mavrogiannopoulos 
Thread-Topic: [TLS] Encrypt-then-MAC again (was Re: padding bug)
Thread-Index: AQHO7R77H2f5vAeCGkOkJhCJPGzqVZo8bsWAgAA2+ACAABbXAIAAHPYAgAAhpACAAPI6AIAAG7aAgAWtiYCAABNLAA==
Date: Wed, 4 Dec 2013 09:20:42 +0000
Message-ID: 
In-Reply-To: <1386144695.2047.30.camel@aspire.lan>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [80.42.211.100]
x-forefront-prvs: 0050CEFE70
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23B0B38CE41DCF45B492F6D0C680094A@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 09:21:00 -0000

Nikos,

On 04/12/2013 08:11, "Nikos Mavrogiannopoulos"  wrote:



>On Sat, 2013-11-30 at 17:29 +0000, Paterson, Kenny wrote:
>
>> 2. It assumes the MAC output size is the same as the block cipher's
>>block
>> size.
>
>That I hadn't notice, and if it is not fixable, it is indeed a strong
>counter-argument against pad-mac-then-encrypt.
>
>> On the plus side, and perhaps this is what you were referring to, Hugo's
>> analysis works just fine for stream-cipher based ciphersuites (as long
>>as
>> the stream cipher is good - so not RC4 then!). The Asiacrypt 2011 paper
>> can be seen as extending his analysis to handle the actual construction
>> used in TLS's CBC-mode ciphersuites, but with the important, necessary,
>> and difficult-to-achieve proviso concerning uniformity of errors.
>
>So as I understand your proof fixes the point (2), that you mentioned
>above?

It should. But, to our continuing embarrassment, the proof is not yet in
the public domain - the published version of the paper does not include
it, because of page limits, and we never got the full version into a shape
that we are happy with. We have more motivation than ever to finish it.

I also believe the Phil Rogaway and co-authors have been examining MtE
versus EtM recently, and should have some new results that give additional
support to MtE provided the encryption scheme satisfies certain natural
properties. I'll see if I can get Phil or his co-authors to post a summary
here, but if you want an advance preview, there's this:

http://2013.diac.cr.yp.to/slides/rogaway.pdf


particularly slides 7 and 8 (but notice the conditions on the encryption
scheme on slide 8).

Cheers

Kenny



From SRS0=SB7s=VL=acm.org=bmoeller@srs.kundenserver.de  Wed Dec  4 01:50:32 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6EB1AE209 for ; Wed,  4 Dec 2013 01:50:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 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.001, SPF_HELO_PASS=-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 XnpXg7lIfjoj for ; Wed,  4 Dec 2013 01:50:30 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 869411AE1D3 for ; Wed,  4 Dec 2013 01:50:29 -0800 (PST)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0Mctwz-1W5x401Dfd-00Hy7A; Wed, 04 Dec 2013 10:50:21 +0100
Received: by mail-ob0-f172.google.com with SMTP id gq1so15907160obb.3 for ; Wed, 04 Dec 2013 01:50:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B9cAwhJAnJozBksm7z5+aKI37d1x/S2vv++RW4AKKgk=; b=C0VuOKnEoFIqQ2V8YptHvPu2OpJTjOsvaN+J5tXHzivNUAAm1UB/9kvH+0LwsEwpWs qGirHKu1B6eW8nTlbHZLjU57TgW8v0UAPNenrHhdpVzFN330ELr8M0oubRNs/47xzNod JhPGBhb2dI1GLuhjIBaGVXAoshX0L1MUPEXbkv91K0zwIHGBgpZE4ZboGUKCdLwiUcDx MXZE5Szi6AUn7Ydy92dgkGfZwLuSLufVyo3LQDa25MkPdGur3GcqtQRPn3L2x8BmieCK Os42kn8eF5sIeFQTj2j1o5VZR0V6hcFxNlRqD/BEEEvOm+98fe6ZPcpvtwfgiJopSI6r IKUw==
MIME-Version: 1.0
X-Received: by 10.60.56.3 with SMTP id w3mr13675553oep.37.1386150620064; Wed, 04 Dec 2013 01:50:20 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Wed, 4 Dec 2013 01:50:19 -0800 (PST)
In-Reply-To: 
References:         
Date: Wed, 4 Dec 2013 10:50:19 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c20a7250750904ecb25788
X-Provags-ID: V02:K0:M2XIm2Ifz0L5PIVCBXeDOhminxCxO1cZfCSWhlhm290 zN47IExI2naM2uTTRgMsDm5gFQgyjE+tdNsDzURGIV8AxbgSn1 9Cd0YyPP61hHfymGoGDOtdjB0D3qAN965fZCHKVpxfN520v9YB T+MBU01ZWJx0Yd5Kh78J/WeTUqXXXvHFpjOlk7SaPBbe7GhNu4 C6gMmRlav5Cc1+coycRKHUjfMzVLNIKrS9PFdsaoIH5GdFbOXb 4PiUYxCuPbpGvQ1jBTLjOM+7YJPSqcjxuwBaE2USPMI8T3h/Kh gZY5tGnHYpyqeiv9PuxfALTYUJrFApV/GvKKg2CDu6me5c4LV8 Swm/4tGpVVT55E6rrPDTvwzmRELMG95gwCQGxdUomLyhFygNsh 4QYkT9yPXe6QMSfg8JFC6QNclSyMWP5V5RRU6vsTIG7vypDXid q37p0
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 09:50:32 -0000

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

> > http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01.
>


1. Why don't you also specify a TLS extension, which can be used when
> we fall back to a lesser TLS version (but not SSL 3.0)?
>
> I assume specifying only a SCSV is for simplicity.
>

Yes, this is for simplicity and efficiency: we need a SCSV codepoint anyway
for fallback cases that can't use extensions, and if we have that, we'd
gain nothing by sometimes sending a (4-byte) extension instead of a
(2-byte) SCSV.  (Unlike RFC 5746's TLS_EMPTY_RENEGOTIATION_INFO_SCSV, the
new TLS_FALLBACK_SCSV isn't just a special case of a more general
extension, and we also don't require any information back from the server
that would require using the extension mechanism.)



> 2. I don't understand why you want the server to report an
> inappropriate fallback only if the client drops below the server's
> highest supported version.
>
> This means an inappropriate fallback is not always reported to the
> client, or it is reported to the client only after multiple fallbacks.
>
> For example, suppose the server supports TLS 1.1 and the client
> supports TLS 1.2.
>
> If a middle box blocks only TLS 1.2 ServerHello and injects a TCP
> Reset (this middle box behavior was observed, not hypothetical), the
> client will retry with a TLS 1.1 ClientHello with the fallback SCSV,
> but the server will then finish the handshake successfully.
>
> On the other hand, if a middle box blocks both TLS 1.2 and TLS 1.1
> ServerHellos and injects a TCP Reset, the client will retry twice,
> first with a TLS 1.1 ClientHello and then with a TLS 1.0 ClientHello.
> Although the ClientHellos in both retries have the fallback SCSV, the
> server will only respond with an inappropriate_fallback alert to the
> second retry.
>
> I think the draft should explain the rationale for this less strict
> server behavior.
>

I'm afraid that I'm not entirely sure I understand what your concern is.

In the second scenario (TLS 1.2 and TLS 1.1 both blocked), the server will
only respond with an inappropriate_fallback alert to the second retry --
but it also wouldn't have a chance to respond to the first retry because it
doesn't see it, due to the middle box aborting that TCP connection.  So no
one would gain anything from sending that alert.

Now let's look at the first scenario (TLS 1.2 blocked by the middle box and
also not supported by the server): in the retry using TLS 1.1, the server
does not send the inappropriate_fallback alert because the client is only
falling back to the TLS version that should have been negotiated anyway: so
this fallback isn't "inappropriate" -- it's annoying from a protocol point
of view (and will typically have a latency impact), but that's just
inherent to the fallback strategy -- the client implements that strategy to
improve interoperability, accepting that protocol overhead.  Whether the
problem for the original connection attempt is caused by the actual
server-side TLS implementation or by something in between should be
irrelevant.

Moreover, if servers were to reject connection attempts with
TLS_FALLBACK_SCSV arriving in their native protocol version, this might
cause a new interoperability nightmare in the future.  Current server
implementations will generally be tested with TLS 1.2 clients, but not
necessarily with clients that send a version number such as 0x03 0x04 (TLS
1.3) or 0x04 0x00 (TLS 2.0?).  They are broken if they don't support that,
but preventing such broken servers from getting rolled out is outside of
the scope of, and not in the power of, this specification.  While I hope
that version intolerance problems can be addressed successfully (thus
rendering TLS_FALLBACK_SCSV irrelevant in practice -- servers will still
need the logic for it, but ideally clients would never actually send it),
that's pretty much orthogonal to this Internet-Draft.  I wouldn't want to
risk arriving at a situation where the server-side logic for
TLS_FALLBACK_SCSV becomes a hindrance for rolling out *new* TLS protocol
versions.

I hope that makes the rationale clearer.  Let me know if it doesn't, though.

Regarding making the draft clearer, I'm considering adding two or three
example cases to the Internet-Draft to discuss how and why
 TLS_FALLBACK_SCSV will allow certain fallbacks and disallow others.




> 3. In the Security Considerations section, we have:
>
>    However, it is particularly strongly recommended to send
>    TLS_FALLBACK_SCSV when downgrading to SSL 3.0 as the CBC cipher
>    suites in SSL 3.0 have weaknesses that cannot be addressed by
>    implementation workarounds like the remaining weaknesses in later
>    (TLS) protocol versions.
>
> It would be nice to name the weaknesses and workarounds explicitly.
> The implicit IV weakness of TLS 1.0 and SSL 3.0 can be worked around
> by record splitting, so I assume that's not the weakness you're
> referring to. Are you referring to the CBC padding timing attacks?
>

Right, I guess this is a little *too* thin on details.  I wanted to avoid
including a snapshot of currently known problems in currently relevant
ciphersuites, which would only distract from the more generally useful
simple mechanism specified in the Internet-Draft (and seems more suited for
a separate BCP document) -- however, if I choose to touch on particular
problems, I'd better say what those are :-)

The specific problem for CBC ciphersuites in SSL 3.0 is that block padding
is not completely specified.  As of TLS 1.0, three-byte padding (say) will
be of the form 0x02 0x02 0x02, but in SSL 3.0, the first two bytes are
allowed to have any value.  Accordingly, SSL 3.0 (unlike TLS 1.0) does not
require the recipient to validate the padding that it receives.  It has
been known for at least ten years (http://www.openssl.org/~bodo/tls-cbc.txt)
that this results in cryptographic insecurity in the presence of an active
adversary.

Unlike the other CBC ciphersuite weaknesses that have more recently made
the news, this problem is supposedly mostly irrelevant because SSL 3.0 is
way more obsolete than TLS 1.1 -- unless you allow an active attacker to
downgrade your connection to SSL 3.0, that is.  If you actually use SSL
3.0, there is *no* backwards-compatible remedy.  All you can do is prevent
unnecessarily falling back to SSL 3.0 (such as by using TLS_FALLBACK_SCSV).



>
> Also, it seems that the main problem with downgrading to SSL 3.0 is
> the loss of features and cipher suites that require TLS extensions,
> such as Server Name Indication and ECC cipher suites. You already
> mentioned that in the Introduction section. If the loss of these
> features and cipher suites degrades security, it should be mentioned
> in the Security Considerations section as well.
>

Good point, this clearly is an essential feature less in that particular
downgrade.



> Finally, the fallback to TLS 1.1 loses AEAD ciphers, and the fallback
> to TLS 1.0 loses the explicit IV for CBC block ciphers (although the
> record splitting workaround is effective). Perhaps these should also
> be mentioned.
>

I'm not that sure about this one given ongoing discussions about supporting
(at least certain) AEAD ciphersuites before TLS 1.2, and given that (as
discussed above) I want to avoid including a snapshot of current security
problem details, which seems best left for a separate BCP document that can
be updated as needed.  (There are several candidate documents in progress;
see here and wpkops.)

Bodo

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


=A0



> http://tools.ietf.org/html/draft-bmoeller-tls-downg=
rade-scsv-01.




1. Why don't you also specify a TLS extension, which can be used when
we fall back to a lesser TLS version (but not SSL 3.0)?



I assume specifying only a SCSV is for simplicity.
Yes, this is for simplicity and efficiency: we need a SCSV code=
point anyway for fallback cases that can't use extensions, and if we ha=
ve that, we'd gain nothing by sometimes sending a (4-byte) extension in=
stead of a (2-byte) SCSV. =A0(Unlike RFC 5746's TLS_EMPTY_RENEGOTIATION=
_INFO_SCSV, the new TLS_FALLBACK_SCSV=A0isn't just a special case of a =
more general extension, and we also don't require any=A0information bac=
k from the server that would require using the extension mechanism.)







2. I don't understand why you want the server to report an

inappropriate fallback only if the client drops below the server's

highest supported version.



This means an inappropriate fallback is not always reported to the

client, or it is reported to the client only after multiple fallbacks.



For example, suppose the server supports TLS 1.1 and the client

supports TLS 1.2.



If a middle box blocks only TLS 1.2 ServerHello and injects a TCP

Reset (this middle box behavior was observed, not hypothetical), the

client will retry with a TLS 1.1 ClientHello with the fallback SCSV,

but the server will then finish the handshake successfully.



On the other hand, if a middle box blocks both TLS 1.2 and TLS 1.1

ServerHellos and injects a TCP Reset, the client will retry twice,

first with a TLS 1.1 ClientHello and then with a TLS 1.0 ClientHello.

Although the ClientHellos in both retries have the fallback SCSV, the

server will only respond with an inappropriate_fallback alert to the

second retry.



I think the draft should explain the rationale for this less strict

server behavior.

I'm afraid that I&=
#39;m not entirely sure I understand what your concern is.

In the second scenario (TLS 1.2 and TLS 1.1 both blocked), the ser=
ver will only respond with an inappropriate_fallback alert to the second re=
try -- but it also wouldn't have a chance to respond to the first retry=
 because it doesn't see it, due to the middle box aborting that TCP con=
nection. =A0So no one would gain anything from sending that alert.



Now let's look at the first scenario (TLS 1.2 block=
ed by the middle box and also not supported by the server): in the retry us=
ing TLS 1.1, the server does not send the inappropriate_fallback alert beca=
use the client is only falling back to the TLS version that should have bee=
n negotiated anyway: so this fallback isn't "inappropriate" -=
- it's annoying from a protocol point of view (and will typically have =
a latency impact), but that's just inherent to the fallback strategy --=
 the client implements that strategy to improve interoperability, accepting=
 that protocol overhead. =A0Whether the problem for the original connection=
 attempt is caused by the actual server-side TLS implementation or by somet=
hing in between should be irrelevant.



Moreover, if servers were to reject connection attempts=
 with TLS_FALLBACK_SCSV arriving in their native protocol version, this mig=
ht cause a new interoperability nightmare in the future. =A0Current server =
implementations will generally be tested with TLS 1.2 clients, but not nece=
ssarily with clients that send a version number such as 0x03 0x04 (TLS 1.3)=
 or 0x04 0x00 (TLS 2.0?). =A0They are broken if they don't support that=
, but preventing such broken servers from getting rolled out is outside of =
the scope of, and not in the power of, this specification. =A0While I hope =
that version intolerance problems can be addressed successfully (thus rende=
ring TLS_FALLBACK_SCSV irrelevant in practice -- servers will still need th=
e logic for it, but ideally clients would never actually send it), that'=
;s pretty much orthogonal to this Internet-Draft. =A0I wouldn't want to=
 risk arriving at a situation where the server-side logic for TLS_FALLBACK_=
SCSV becomes a hindrance for rolling out *new* TLS protocol versions.



I hope that makes the rationale clearer. =A0Let me know=
 if it doesn't, though.

Regarding making the d=
raft clearer, I'm considering adding two or three example cases to the =
Internet-Draft to discuss how and why =A0TLS_FALLBACK_SCSV will allow certa=
in fallbacks and disallow others.




=A0

3. In the Security Considerations section, we have:



=A0 =A0However, it is particularly strongly recommended to send

=A0 =A0TLS_FALLBACK_SCSV when downgrading to SSL 3.0 as the CBC cipher

=A0 =A0suites in SSL 3.0 have weaknesses that cannot be addressed by

=A0 =A0implementation workarounds like the remaining weaknesses in later
=A0 =A0(TLS) protocol versions.



It would be nice to name the weaknesses and workarounds explicitly.

The implicit IV weakness of TLS 1.0 and SSL 3.0 can be worked around

by record splitting, so I assume that's not the weakness you're

referring to. Are you referring to the CBC padding timing attacks?

Right, I guess this is a little *too* thin on d=
etails. =A0I wanted to avoid including a snapshot of currently known proble=
ms in currently relevant ciphersuites, which would only distract from the m=
ore generally useful simple mechanism specified in the Internet-Draft (and =
seems more suited for a separate BCP document) -- however, if I choose to t=
ouch on particular problems, I'd better say what those are :-)



The specific problem for CBC ciphersuites in SSL 3.0 is=
 that block padding is not completely specified. =A0As of TLS 1.0, three-by=
te padding (say) will be of the form 0x02 0x02 0x02, but in SSL 3.0, the fi=
rst two bytes are allowed to have any value. =A0Accordingly, SSL 3.0 (unlik=
e TLS 1.0) does not require the recipient to validate the padding that it r=
eceives. =A0It has been known for at least ten years (http://www.openssl.org/~bodo/tls-cbc.txt) that this results in cryptographic insecurity in the presence of an acti=
ve adversary.



Unlike the other CBC ciphersuite weaknesses that have m=
ore recently made the news, this problem is supposedly mostly irrelevant be=
cause SSL 3.0 is way more obsolete than TLS 1.1 -- unless you allow an acti=
ve attacker to downgrade your connection to SSL 3.0, that is. =A0If you act=
ually use SSL 3.0, there is *no* backwards-compatible remedy. =A0All you ca=
n do is prevent unnecessarily falling back to SSL 3.0 (such as by using TLS=
_FALLBACK_SCSV).



=A0



Also, it seems that the main problem with downgrading to SSL 3.0 is

the loss of features and cipher suites that require TLS extensions,

such as Server Name Indication and ECC cipher suites. You already

mentioned that in the Introduction section. If the loss of these

features and cipher suites degrades security, it should be mentioned

in the Security Considerations section as well.

Good point, this clearly is an essential feature less in that part=
icular downgrade.






Finally, the fallback to TLS 1.1 loses AEAD ciphers, and the fallback

to TLS 1.0 loses the explicit IV for CBC block ciphers (although the

record splitting workaround is effective). Perhaps these should also

be mentioned.

I'm not that sure abo=
ut this one given ongoing discussions about supporting (at least certain) A=
EAD ciphersuites before TLS 1.2, and given that (as discussed above) I want=
 to avoid including a snapshot of current security problem details, which s=
eems best left for a separate BCP document that can be updated as needed. =
=A0(There are several candidate documents in progress; see here and=A0wpkop=
s.)



Bodo



--001a11c20a7250750904ecb25788--

From martin.thomson@gmail.com  Wed Dec  4 09:21:12 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A3D1AE160 for ; Wed,  4 Dec 2013 09:21:12 -0800 (PST)
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 CxmSGpEHF44B for ; Wed,  4 Dec 2013 09:21:11 -0800 (PST)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4DA1AE006 for ; Wed,  4 Dec 2013 09:21:10 -0800 (PST)
Received: by mail-we0-f176.google.com with SMTP id w62so9580492wes.21 for ; Wed, 04 Dec 2013 09:21:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QoR8P1wiogsE+ZZ4/0DjYgTvI8MQiOx+9pAiX4aFTHs=; b=vqSjo4o+1Wg47jf0gg7g0k0imai2zufapGaY7R2YLMHT7d8GrtTdLQl9dXyTuLIzZJ M5vDgXf6jVh/6WMzGZShcxv0ua/U/7RqHi2GHcp0z9XsASs/5DviG7r4k7dTVD6HtKnL JQ6D/xg/A6Ya9bc8GPfynbPuc3F31ur2IetLCnSRaWt+3lclF2YtVVsKAj0wgZJRu02Q 9ENohVn3KznWy/ogsECZpuKXPp4V00DEa9Bk91Y8iuumyh7h/BLoFaf4JqF5WXtg5bNP kciUYW9Vfei+kuu2/fMKeoAmESRGj57pcfA/+KcLxTXZQJ43R9BbB/L3Lme5BLv3uLPD Ry6g==
MIME-Version: 1.0
X-Received: by 10.180.101.230 with SMTP id fj6mr8122194wib.58.1386177667676; Wed, 04 Dec 2013 09:21:07 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Wed, 4 Dec 2013 09:21:07 -0800 (PST)
In-Reply-To: <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>  <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com>
Date: Wed, 4 Dec 2013 09:21:07 -0800
Message-ID: 
From: Martin Thomson 
To: Marsh Ray 
Content-Type: text/plain; charset=UTF-8
Cc: "" 
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 17:21:12 -0000

On 3 December 2013 19:13, Marsh Ray  wrote:
> Microsoft clients and servers have supported it for years now but it has been off by default.

I probably shouldn't be the one telling you this, but IE11 offers 1.2
now.  And I think that 1.2 has been accepted by IIS since Windows
Server 2008.  :)  Just more information in support of your thesis.
The MS HTTP folks did some testing and found that of the sites they
connected to (~1 million), around 16% accepted 1.2.

(Caveat: not my numbers, just my memory, you can ask Rob Trace for details.)

From watsonbladd@gmail.com  Wed Dec  4 10:43:10 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539D11AE120 for ; Wed,  4 Dec 2013 10:43:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_45=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 D9BRmpeOrLLJ for ; Wed,  4 Dec 2013 10:43:09 -0800 (PST)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 371FB1AD8F7 for ; Wed,  4 Dec 2013 10:43:09 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id p61so15083152wes.8 for ; Wed, 04 Dec 2013 10:43:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=V3HG3fHSUiCftk4fmLkmjbPDtGK692BeSF2mDjAtrYo=; b=bANWjTzr0sE7qVcbWi/xCEUYKKyAd3J7VQufAAxXDl2leg6EnfAnQKn1V9wD62joCN 2bb4EefedT2sOKjG1GlOH2Z9iH4Zup2QJsf3ms7Qt/RaTXXfgseNgR3PJXRGWLPoXDyT qs0oBC6per5NLDK0bkeinnEkwNy2kUfWwfJfjedqWeDjDxHurw0sB1qdF2o031Il2U/2 lnyyWdFXmeraYgpb7Z6ps3m6Xg848RMiUqbxgNDlTDE6QyDOf+J5+t0O7Hkkv3ylNlSg yLbTXhzDtcdaPCNvFAFK8LVIG5HZ0hc1TuR+0F12nLcOezwXbURhB3hTA1umXvDjEI7R TG0Q==
MIME-Version: 1.0
X-Received: by 10.180.7.136 with SMTP id j8mr8622859wia.17.1386182585714; Wed, 04 Dec 2013 10:43:05 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Wed, 4 Dec 2013 10:43:05 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Wed, 4 Dec 2013 10:43:05 -0800 (PST)
Date: Wed, 4 Dec 2013 10:43:05 -0800
Message-ID: 
From: Watson Ladd 
To: Kenny Paterson 
Content-Type: multipart/alternative; boundary=14dae9cdc8ff9d92ba04ecb9c8cd
Cc: tls@ietf.org
Subject: [TLS] On the efficency of ETA.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 18:43:10 -0000

--14dae9cdc8ff9d92ba04ecb9c8cd
Content-Type: text/plain; charset=UTF-8

CBC is IV based, not nonce based. Turning it into a nonce - based scheme
requires an additional cipher call, and a reexamination of the security
proof. (Naive use of the Bernstein interpolation lemma leads to quartic
loss as we already have quadratic loss in CBC)

That leaves us with the IV based constructions which all require three
invocations of the MAC. Let's just stick with counter mode+nonce based MAC:
the efficient, obviously secure choice.
Sincerely,
Watson Ladd

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


CBC is IV based, not nonce based. Turning it into a nonce - =
based scheme requires an additional cipher call, and a reexamination of the=
 security proof. (Naive use of the Bernstein interpolation lemma leads to q=
uartic loss as we already have quadratic loss in CBC)



That leaves us with the IV based constructions which all req=
uire three invocations of the MAC. Let's just stick with counter mode+n=
once based MAC: the efficient, obviously secure choice.

Sincerely,

Watson Ladd




--14dae9cdc8ff9d92ba04ecb9c8cd--

From wtc@google.com  Wed Dec  4 10:59:29 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FE61AD943 for ; Wed,  4 Dec 2013 10:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 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.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 5X8fM_xcxkhw for ; Wed,  4 Dec 2013 10:59:27 -0800 (PST)
Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 65AD71AD8F4 for ; Wed,  4 Dec 2013 10:59:27 -0800 (PST)
Received: by mail-vc0-f173.google.com with SMTP id ia6so12087910vcb.32 for ; Wed, 04 Dec 2013 10:59:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qbiXRsiQ5OxlUb/caVEx9Qpg4jF4hvqK1WB/fOAxoyE=; b=JtDelzAlSJ7SevyIeUJcTLTPlLRudR9Csfq9iqOx5qkDIYNiR0Yt1HRHV4/nGBERTH Qu7WfktN7sqKN6HyyxD+JJieBKl0woNpAU5cBwMjWpSNQjmIIMyZ7LLuEhlh4eFCJ7KH DkYFns4zIFOz57YRQhTIB7bKr0kN3PX8nZRy6FmBlb7G4z+Vm4KdOUPQhrESbtKVcOnQ FZeXsq+kGZy8Vkyi3V3bZlJJwvQ+sSkncK7Ia8lLJu7crlfeaLslXtvr/FGqAjwzI9Ck G5mzOPaq/cY9kNIqTRf6VDGjREe7S35QovvmZumrUTc7ETcsZWxEB/WbsnBs+XK/SS/p KwVA==
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=qbiXRsiQ5OxlUb/caVEx9Qpg4jF4hvqK1WB/fOAxoyE=; b=XgHSUoMQK0bSh7dQzAnVGV1CP20rN5BzdfEKo6LbIPsbZcCCVtoGZfFWn/WX8ufcGa muGls6bBfVBUEE9qHbI/IeqSecwqV1yPDVto8KpFnAbxJW40CIBOCFa9ZDBd1bjBAs7x mwBgxd2oK2HZKXNxh1xQZYuhwe1iDiMXF6IjrhgXGx7IG4h+aMQQbITC2gS2EgxWkTVZ OLKcgJSYM673Y1RxoOrF4jinmtsXeHL+6Fkr5Q6NN9QjA2PqlgBYUx+03jqIF91QmgUj NiejJyxXMqPhkPdk93Ms2LQmLl0cpoDWWmvKXhXw5dxn2kFv9VUM9U50JdWIMyZrBQor fTWA==
X-Gm-Message-State: ALoCoQmw4H7UWn2dyu1eUGQ38QJ4k/z1Ywnnf9/5B75efy/QjX53asxlVRfJ06x293iDo1iEtfwpjU1scJBAtUcMnFfqiZRb6JYVXuRMXBO/8greMnawSgFOLcD/Jy1o7yvq2wtdfT15/HHex+Mq3O8VC9UzixQQIxeSwGqSq3WxWqPYoRBWNQLpXObeqihp5fI7f9MJ9eAl
MIME-Version: 1.0
X-Received: by 10.220.11.7 with SMTP id r7mr60622436vcr.12.1386183563876; Wed, 04 Dec 2013 10:59:23 -0800 (PST)
Received: by 10.52.167.10 with HTTP; Wed, 4 Dec 2013 10:59:23 -0800 (PST)
In-Reply-To: 
References:          
Date: Wed, 4 Dec 2013 10:59:23 -0800
Message-ID: 
From: Wan-Teh Chang 
To: Bodo Moeller 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 18:59:29 -0000

Bodo,

Thank you for your reply.

1. Re: a TLS extension vs. a SCSV:

I asked about an extension partly because RFC 5746 uses a dual
extension-SCSV approach, and partly because I wondered if it is useful
for the client to indicate its actual highest supported version in an
extension.

However, I can't come up with a reason why the client's actual highest
version is useful to a server. Although Eric Rescorla and Adam's old
proposals ([1] and [2]) also included the client's actual highest
version (which necessitated multiple, version-specific SCSVs), careful
analysis of their old proposals showed that that version is only
compared with ClientHello.client_version. The boolean result of that
comparison is equivalent to your TLS_FALLBACK_SCSV.

2. Re: the less strict server behavior you specified:

I realized that my example of a client and a server with an
interfering middle box has mistakes. I am sorry that I wasted your
time analyzing an incorrect example.

In spite of my mistake, your reply answered my question, here:

On Wed, Dec 4, 2013 at 1:50 AM, Bodo Moeller  wrote:
>
> Moreover, if servers were to reject connection attempts with
> TLS_FALLBACK_SCSV arriving in their native protocol version, this might
> cause a new interoperability nightmare in the future.  Current server
> implementations will generally be tested with TLS 1.2 clients, but not
> necessarily with clients that send a version number such as 0x03 0x04 (TLS
> 1.3) or 0x04 0x00 (TLS 2.0?).  They are broken if they don't support that,
> but preventing such broken servers from getting rolled out is outside of the
> scope of, and not in the power of, this specification.

I don't fully agree with this rationale. The work to implement TLS
version negotiation correctly should be similar to the work to add
support for TLS_FALLBACK_SCSV. Why don't we require that servers that
support TLS_FALLBACK_SCSV must also do version negotiation correctly?
RFC 5746 has such a requirement:

   TLS servers implementing this specification MUST ignore any unknown
   extensions offered by the client and they MUST accept version numbers
   higher than their highest version number and negotiate the highest
   common version.  These two requirements reiterate preexisting
   requirements in RFC 5246 and are merely stated here in the interest
   of forward compatibility.

Do you think it is reasonable for a server to reject a currently
undefined ClientHello.client_version (such as TLS 1.3 or TLS 2.0)? Or
do you think that if something is not tested, it is likely to be
broken? Although I think the latter is true in general, in this
particular case, I think the risk is low. So you are taking a very
conservative approach.

> Regarding making the draft clearer, I'm considering adding two or three
> example cases to the Internet-Draft to discuss how and why
> TLS_FALLBACK_SCSV will allow certain fallbacks and disallow others.

Yes, explaining why you want to allow certain fallbacks would be
helpful, because most people's first thought (as evidenced by my
question and Eric and Adam's old proposals) is to specify a strict
server behavior.

3. Re: the Security Considerations section:

Thank you for explaining what the CBC weaknesses you referred to are.

On second thought, I now suggest that the Security Considerations
section should only consider the security issues of TLS_FALLBACK_SCSV
itself. The section doesn't need to describe the security weaknesses
of SSL 3.0 or older versions of TLS. I agree that would be a
distraction from the simple TLS_FALLBACK_SCSV mechanism specified in
the draft.

4. Why do you not use the server's support of the renegotiation_info
extension as a signal ([3])? Is it because you want to allow servers
to opt in to the fallback prevention mechanism?

Wan-Teh Chang

[1] http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt
[2] http://www.ietf.org/mail-archive/web/tls/current/msg08861.html
[3] http://tools.ietf.org/html/draft-pettersen-tls-version-rollback-removal-02

From mpg@elzevir.fr  Wed Dec  4 11:12:40 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888161ADFC2 for ; Wed,  4 Dec 2013 11:12:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.251
X-Spam-Level: 
X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-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 oD6sOkNAOJEK for ; Wed,  4 Dec 2013 11:12:38 -0800 (PST)
Received: from mordell.elzevir.fr (mordell.elzevir.fr [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by ietfa.amsl.com (Postfix) with ESMTP id 02AC61AD945 for ; Wed,  4 Dec 2013 11:12:38 -0800 (PST)
Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 72C30160C7; Wed,  4 Dec 2013 20:12:31 +0100 (CET)
Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 9031229849; Wed,  4 Dec 2013 20:12:29 +0100 (CET)
Message-ID: <529F7E9D.80302@elzevir.fr>
Date: Wed, 04 Dec 2013 20:12:29 +0100
From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
To: Wan-Teh Chang , Bodo Moeller 
References:           
In-Reply-To: 
X-Enigmail-Version: 1.6
OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 19:12:40 -0000

Hi,

On 04/12/2013 19:59, Wan-Teh Chang wrote:
> I don't fully agree with this rationale. The work to implement TLS
> version negotiation correctly should be similar to the work to add
> support for TLS_FALLBACK_SCSV. Why don't we require that servers that
> support TLS_FALLBACK_SCSV must also do version negotiation correctly?

Unless I'm mistaken, the problem TLS_FALLBACK_SCSV tries to adress is not
servers that don't implement version negotiation correctly, but MITM actively
doing a downgrade attack (and faulty middleboxes, which have the same effect).

Manuel.

From agl@google.com  Wed Dec  4 11:20:14 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D591AE2EA for ; Wed,  4 Dec 2013 11:20:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.08
X-Spam-Level: 
X-Spam-Status: No, score=-1.08 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, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-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 v92p_sZcb_xb for ; Wed,  4 Dec 2013 11:20:13 -0800 (PST)
Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 43D0B1AE2D7 for ; Wed,  4 Dec 2013 11:20:13 -0800 (PST)
Received: by mail-ve0-f179.google.com with SMTP id jw12so12494663veb.38 for ; Wed, 04 Dec 2013 11:20:10 -0800 (PST)
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:content-transfer-encoding; bh=lWx//b2piBZG0w3yGgYdvAr9a6YgvaXbDGRgMlVMlR4=; b=NZFYBct8wErYRf9ihuxq6UMNXDiUhyWTH0gTq+2FtAtW1X9qvfwFbGVFrhsDN0hsqb 7nqPZC0SxzyqUi+wmbN/qNUgqDE5RdW0X4cpYuq/A1h/SkGK4PgZkNd+O4tEEu57xvHN q8iNReZQ7/GF8DHNe6s2CDcOQGGsCyd+f8ESckLkOvKR/rrJa71Q3LtkZNy8hNxCe65U NerOiCX4V9aaqeMz+yyqf+rKwJOH9O1paT4ReFFYxbPauvLOFaq3R4gUEfWnQqoBDLJ/ QhJRCN36slsCVF6etAFGmu5Qj5bWsE9rVce8NNZGAiWcOT2j8S86EX/jlkPeYVgY50ul mnEg==
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:content-transfer-encoding; bh=lWx//b2piBZG0w3yGgYdvAr9a6YgvaXbDGRgMlVMlR4=; b=J2Ys8td+U8eRofaFYSSeDJ72TJnlYDrYB/7Lkfeczhr9p5oYgYpwzPmNylNlRQX5Q4 YYlL4XNGLJuT/CZhF9aWVFmKsBo4N/1AbRbUQiWvt4IsDTdfkVlbrfq4Sx4GRJmRlMpB 3rzG1BnkcY1ezfkJmI52RMB/yymx92HeJrvJYO5unCjv73UsVTRK0ncd7uPBATgvWCvR JP2tDtL8t7dQHY9cfVNIZNhQasqrHNE+PtBURI0Vj927FBsdckSuurBfML0HyfoiAgI0 wB+lBvwMjXKXHK/OuPZUPhd879+V7AQ17MB1Vf4XEE0xlQ53NcnsNPVk/GQNzKJZB372 m8Tg==
X-Gm-Message-State: ALoCoQl2gimeys7ER+qk+1Cu2Ek1F82ajp77lRsYZPhUaTpu6cS4D6jZNBn/Wdo1/JE8XH35lQmmGY4Ac4gbQcwpBrcWcgRQN9mFG41bm6MgjaPeBNG8eDx80cEzCznb0W4IxC4VHk+axbkWnyAYyM3BOPJkFdsO0oBxWvL5tPstuV3KnDrVc8a57djrj5fnvMr8jI2vwFZl
X-Received: by 10.52.64.140 with SMTP id o12mr1716074vds.40.1386184809890; Wed, 04 Dec 2013 11:20:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Wed, 4 Dec 2013 11:19:49 -0800 (PST)
In-Reply-To: <529F7E9D.80302@elzevir.fr>
References:            <529F7E9D.80302@elzevir.fr>
From: Adam Langley 
Date: Wed, 4 Dec 2013 14:19:49 -0500
Message-ID: 
To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 19:20:14 -0000

On Wed, Dec 4, 2013 at 2:12 PM, Manuel P=C3=A9gouri=C3=A9-Gonnard  wrote:
> Unless I'm mistaken, the problem TLS_FALLBACK_SCSV tries to adress is not
> servers that don't implement version negotiation correctly, but MITM acti=
vely
> doing a downgrade attack (and faulty middleboxes, which have the same eff=
ect).

I think the chain of sadness goes like this:

1) Some servers don't implement version negotiation correctly, or have
other bugs that happen to be solved by using SSLv3.
2) Therefore some clients implement fallback
3) Therefore attackers can trigger fallback even with correct servers.

The MITM proxies that also had downgrade bugs caused issues with a
Chrome experiment where we removed SSLv3 fallback for Google
properties because it looked, to the client, like an attack. But,
since it's a MITM proxy, it's an attack that the user has authorised.


Cheers

AGL

From SRS0=SB7s=VL=acm.org=bmoeller@srs.kundenserver.de  Wed Dec  4 13:05:36 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA271AE334 for ; Wed,  4 Dec 2013 13:05:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 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.001, SPF_HELO_PASS=-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 94Sz5HiuQmeg for ; Wed,  4 Dec 2013 13:05:33 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id F201D1AE30A for ; Wed,  4 Dec 2013 13:05:32 -0800 (PST)
Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LwmZo-1VYrDc0pwW-016JMo; Wed, 04 Dec 2013 22:05:28 +0100
Received: by mail-ob0-f174.google.com with SMTP id wn1so16673604obc.19 for ; Wed, 04 Dec 2013 13:05:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iO1gV/669D5mREPhHhBIgYrGjqYBxcfoLqU1FsqZCxM=; b=Hxh312sTh92GiCyJFzAwYTsJZ4drvwp3z9Yab1/4NULc2k87t2qhnAAIJ/ThYVX6X6 p1Kg9x3yzW4F0+TrCyITwgEI7/LbVzhpFhhLz8x/Cf12W3jc0qm20NnhZvwpa85iDPIU PwuGA/1QKOZP4VUF4lgRnezdwwhh5d1xa0oc5x3rl69Nk9NvtfdsnBYxJrLNW9qvDJJ+ mcRMPmKSPlGC57WY4rHqMs6GAGlkwk+qV8tKTLKGuBaeOZYHhJ1wEcipSUDywPDBH2uU G1x4pXtY7ivS34FjbmruMiV0I9zkW3gvkDq/a4rp050z54GqS15+hmQPtEqc7OtI8nWU UDpw==
MIME-Version: 1.0
X-Received: by 10.182.223.37 with SMTP id qr5mr15846019obc.41.1386191127003; Wed, 04 Dec 2013 13:05:27 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Wed, 4 Dec 2013 13:05:26 -0800 (PST)
In-Reply-To: 
References:           
Date: Wed, 4 Dec 2013 22:05:26 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=f46d0444ee69b74bc104ecbbc5c5
X-Provags-ID: V02:K0:WQlZ8Dm6+C/+UOj3T5wd/TqHDTrSh220iSiza/4dqZm Yzx5UTp6dlj0uILQNLmgl2d3vIS8QsCm+ogQ1zI4VMa6CuAesW 5nz+K3h+zXptoC218i1pv5I/msOOxyuFaag2Pk1ZFSe0WakHB3 rW9bmHXLsiV0MXCl6iVjGvZDDiTQyBPTaeTGwpEGJphYsV1I5q U3Ni7kUIEOI0snwGTydGa8PKX1bm8z1/5A+ANo/NpIhIrokh1r hTmYfVleIvO5YlPZfY/M328fkEyKRA+PpzoFqVX10HMqDi7H2b mZx+00QQl5dj4tVn0ZI952o/XmZZZzUu/70bumRCS6Gx2B6uRq h5m1sGWbSKJ93ZnRMgQthMMs83c6Ua8+2q+Gbgqtq7KfGlvnHd iwMxthpNFZLeb5SOL2YzSLu3lUXUxst2w79DFuUI8TFaxGa6xy qKeZR
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 21:05:36 -0000

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

Wan-Teh Chang :


> However, I can't come up with a reason why the client's actual highest
> version is useful to a server. Although Eric Rescorla and Adam's old
> proposals ([1] and [2]) also included the client's actual highest
> version (which necessitated multiple, version-specific SCSVs), careful
> analysis of their old proposals showed that that version is only
> compared with ClientHello.client_version. The boolean result of that
> comparison is equivalent to your TLS_FALLBACK_SCSV.
>

Right. This single SCSV is the simplest tool that does the job (and because
it is simple, also easy to get right in implementations).


The work to implement TLS
> version negotiation correctly should be similar to the work to add
> support for TLS_FALLBACK_SCSV. Why don't we require that servers that
> support TLS_FALLBACK_SCSV must also do version negotiation correctly?
> RFC 5746 has such a requirement:
>

All standards-compliant TLS servers are already required to do version
negotiation correctly -- otherwise they wouldn't be standards-compliant TLS
servers :-)  The problem is, something that *appears* to be a
standards-compliant TLS server (and acts exactly like a standards-compliant
TLS server, as far as interactions with current standards-compliant TLS
clients are concerned) may not actually be standards-compliant: current
standards-compliant TLS clients won't ever indicate version TLS 1.3, so
incorrect protocol version negotiation behavior wouldn't be obvious.

Also remember that even if the actual TLS server implementation is
standards-compliant (in particular, version tolerant), a middlebox may
break that, by rejecting ClientHellos with versions that it doesn't
understand.  Such middleboxes clearly are broken, but that alone doesn't
prevent them from getting deployed.


Do you think it is reasonable for a server to reject a currently
> undefined ClientHello.client_version (such as TLS 1.3 or TLS 2.0)? Or
> do you think that if something is not tested, it is likely to be
> broken? Although I think the latter is true in general, in this
> particular case, I think the risk is low. So you are taking a very
> conservative approach.
>

I don't really think that it is *reasonable* for a server (or middlebox) to
reject that, but I wouldn't want to bet the usefulness
of draft-bmoeller-tls-downgrade-scsv-01 on servers (and middleboxes) being
that reasonable.



> 4. Why do you not use the server's support of the renegotiation_info
> extension as a signal ([3])? Is it because you want to allow servers
> to opt in to the fallback prevention mechanism?


[3]
> http://tools.ietf.org/html/draft-pettersen-tls-version-rollback-removal-02
>


I don't want to allow servers to opt in to or opt out of TLS_FALLBACK_SCSV.
 Rather, I want *all* servers to be strict about TLS_FALLBACK_SCSV -- hence
the word "MUST" in the specification of server-side behavior.  This allows
client implementations to send or not send the SCSV based on their security
needs (the draft says that clients SHOULD include
ClientHello.cipher_suites when falling back to a lower protocol version,
where the word "SHOULD" means that "there may exist valid reasons in
particular circumstances to ignore a particular item, but the full
implications must be understood and carefully weighed"; RFC 2119).

I don't think that the server's support of the renegotiation_info extension
is necessarily the right signal in practice: for example, if the server
supports it, you might still be deploying a broken version-intolerant
middlebox without anyone noticing that something's wrong.  Maybe, as
described in draft-pettersen-tls-version-rollback-removal-02, such breakage
will eventually become irrelevant in practice, and thus we'll avoid the
need for fallback connections: once we're there, TLS_FALLBACK_SCSV wouldn't
generally be seen on the wire in normal usage (servers would still watch
out for it, but if no client has a need to fall back to earlier protocol
versions, it wouldn't ever be sent).  In this case,
draft-bmoeller-tls-downgrade-scsv-01
won't be doing any harm (it merely requires a small amount of additional
server-side logic).  Well, upon starting to deploy TLS 1.3 or any other
future version, the future us might find out that there *is* then a (new)
need for fallback connections after all, to allow clients to try TLS 1.3 in
the presence of version-intolerant servers and/or middleboxes that, up to
then, didn't appear to be broken.  In that case, the TLS_FALLBACK_SCSV
mechanism will be useful again, until all the version-intolerant servers
and middleboxes have been removed.  Rinse, repeat: with each new protocol
version, TLS_FALLBACK_SCSV may become relevant again until all servers and
middleboxes intolerant to that new protocol version have been evicted from
the internet.

Generally, getting something like TLS_FALLBACK_SCSV deployed on *many*
servers (so that clients can benefit from it at least for many of their
connections) seems more easily feasible than getting rid of (nearly) *all*
broken servers and middleboxes (so that clients can live entirely without
protocol fallback strategies).  So TLS_FALLBACK_SCSV certainly can be
deployed much quicker (if you are interested in keeping some
interoperability with broken servers -- which of course is why protocol
fallbacks are an issue in the first place): To newly roll it out on a
server, you have to make sure that that server (and any middleboxes
handling the traffic to it) support or tolerate the *currently* deployed
TLS versions, which something that you'd automatically be observing in
standard interoperability testing (as long as you use a client supporting
the current TLS version, with TLS_FALLBACK_SCSV for any protocol fallbacks).

As I've said before, you can do both: deploy TLS_FALLBACK_SCSV for best
security even if protocol fallbacks are sometimes necessary; deploy
draft-pettersen-tls-version-rollback-removal-02
to get rid of the need for those fallback connections as soon as we can.
 There's no conflict between these, rather they complement each other --
draft-pettersen-tls-version-rollback-removal-02 doesn't seem right as a
security fix (because (1) you'll have to clean out broken servers and
middleboxes from the internet before you can actually deploy it, and (2)
once we've fixed the internet accordingly, a new TLS version may surface
more breakage), while draft-bmoeller-tls-downgrade-scsv-01 does nothing to
avoid those protocol "downgrades" in which you're only falling back to the
protocol that should have been negotiated anyway.

Bodo

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


Wan-=
Teh Chang <wtc@google.com>:
=A0


However, I can't come up with a reason why the client's actual high=
est

version is useful to a server. Although Eric Rescorla and Adam's old
proposals ([1] and [2]) also included the client's actual highest

version (which necessitated multiple, version-specific SCSVs), careful

analysis of their old proposals showed that that version is only

compared with ClientHello.client_version. The boolean result of that

comparison is equivalent to your TLS_FALLBACK_SCSV.
Right. This single SCSV is the simplest tool that does the job=
 (and because it is simple, also easy to get right in implementations).

=A0

The work to implement TLS

version negotiation correctly should be similar to the work to add

support for TLS_FALLBACK_SCSV. Why don't we require that servers that
support TLS_FALLBACK_SCSV must also do version negotiation correctly?

RFC 5746 has such a requirement:

All st=
andards-compliant TLS servers are already required to do version negotiatio=
n correctly -- otherwise they wouldn't be standards-compliant TLS serve=
rs :-) =A0The problem is, something that *appears* to be a standards-compli=
ant TLS server (and acts exactly like a standards-compliant TLS server, as =
far as interactions with current standards-compliant TLS clients are concer=
ned) may not actually be standards-compliant: current standards-compliant T=
LS clients won't ever indicate version TLS 1.3, so incorrect protocol v=
ersion negotiation behavior wouldn't be obvious.



Also remember that even if the actual TLS server implem=
entation is standards-compliant (in particular, version tolerant), a middle=
box may break that, by rejecting ClientHellos with versions that it doesn&#=
39;t understand. =A0Such middleboxes clearly are broken, but that alone doe=
sn't prevent them from getting deployed.





Do you think it is reasonable for a server to reject a currently

undefined ClientHello.client_version (such as TLS 1.3 or TLS 2.0)? Or

do you think that if something is not tested, it is likely to be

broken? Although I think the latter is true in general, in this

particular case, I think the risk is low. So you are taking a very

conservative approach.

I don't real=
ly think that it is *reasonable* for a server (or middlebox) to reject that=
, but I wouldn't want to bet the usefulness of=A0draft-bmoeller-tls-dow=
ngrade-scsv-01 on servers (and middleboxes) being that reasonable.



=A0

4. Why do you not use the server's support of the renegotiation_info
extension as a signal ([3])? Is it because you want to allow servers

to opt in to the fallback prevention mechanism?

=


[3]=A0http://tools.ietf.org/html/draft-pettersen-tls-version-rollback-remo=
val-02=A0



I don't want to allow servers to opt in to or opt o=
ut of=A0TLS_FAL=
LBACK_SCSV. =A0Rather, I want *all* servers to be strict about=A0TLS_FALLBACK_SCSV =
-- hence the word "MUST" in the specification of server-side beha=
vior. =A0This allows client implementations to send or not send the SCSV based on t=
heir security needs (the draft says that clients=A0SHOULD include ClientHello.cipher_suites=A0when falling bac=
k to a lower protocol version, where the word "SHOULD" means that=
 "there may exist valid reasons in particular circumstances to ignore =
a particular item, but the full implications must be understood and careful=
ly weighed"; RFC 2119).



I don't thi=
nk that the server's support of the renegotiation_info extension is nec=
essarily the right signal in practice: for example, if the server supports =
it, you might still be deploying a broken version-intolerant middlebox with=
out anyone noticing that something's wrong. =A0Maybe, as described in d=
raft-pettersen-tls-version-rollback-removal-02, such breakage will eventual=
ly become irrelevant in practice, and thus we'll avoid the need for fal=
lback connections: once we're there,=A0TLS_FALLBACK_SCSV wouldn't generally be see=
n on the wire in normal usage (servers would still watch out for it, but if=
 no client has a need to fall back to earlier protocol versions, it wouldn&=
#39;t ever be sent). =A0In this case,=A0draft-bmoeller-tls-downgrade-scsv-01 won't be doing any harm (it m=
erely requires a small amount of additional server-side logic). =A0Well, up=
on starting to deploy TLS 1.3 or any other future version, the future us mi=
ght find out that there *is* then a (new) need for fallback connections aft=
er all, to allow clients to try TLS 1.3 in the presence of version-intolera=
nt servers and/or middleboxes that, up to then, didn't appear to be bro=
ken. =A0In that case, the=A0TLS_FALLBACK_SCSV mechanism will be useful again, until=
 all the version-intolerant servers and middleboxes have been removed. =A0R=
inse, repeat: with each new protocol version,=A0TLS_FALLBACK_SCSV may become releva=
nt again until all servers and middleboxes intolerant to that new protocol =
version have been evicted from the internet.



Generally, getting something l=
ike=A0TL=
S_FALLBACK_SCSV=A0deployed on *many* servers (so that clients can benefit from it a=
t least for many of their connections) seems more easily feasible than gett=
ing rid of (nearly) *all* broken servers and middleboxes (so that clients c=
an live entirely without protocol fallback strategies). =A0So=A0TLS_FALLBACK_SCSV c=
ertainly can be deployed much quicker (if you are interested in keeping som=
e interoperability with broken servers -- which of course is why protocol f=
allbacks are an issue in the first place): To newly roll it out on a server=
, you have to make sure that that server (and any middleboxes handling the =
traffic to it) support or tolerate the *currently* deployed TLS versions, w=
hich something that you'd automatically be observing in standard intero=
perability testing (as long as you use a client supporting the current TLS =
version, with=A0TLS_FALLBACK_SCSV for any protocol fallbacks).



As =
I've said before, you can do both: deploy=A0TLS_FALLBACK_SCSV for best security=
 even if protocol fallbacks are sometimes necessary; deploy=A0draft-=
pettersen-tls-version-rollback-removal-02 to get rid of the need for those =
fallback connections as soon as we can. =A0There's no conflict between =
these, rather they complement each other -- draft-pettersen-tls-version-rol=
lback-removal-02 doesn't seem right as a security fix (because (1) you&=
#39;ll have to clean out broken servers and middleboxes from the internet b=
efore you can actually deploy it, and (2) once we've fixed the internet=
 accordingly, a new TLS version may surface more breakage), while=A0draft-b=
moeller-tls-downgrade-scsv-01 does nothing to avoid those protocol "do=
wngrades" in which you're only falling back to the protocol that s=
hould have been negotiated anyway.



Bodo



--f46d0444ee69b74bc104ecbbc5c5--

From maray@microsoft.com  Wed Dec  4 15:05:54 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4D71AE2AC for ; Wed,  4 Dec 2013 15:05:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 x0twUJT6qdJG for ; Wed,  4 Dec 2013 15:05:52 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6751AE285 for ; Wed,  4 Dec 2013 15:05:51 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB073.namprd03.prod.outlook.com (10.255.241.153) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 4 Dec 2013 23:05:45 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.159]) with mapi id 15.00.0820.005; Wed, 4 Dec 2013 23:05:45 +0000
From: Marsh Ray 
To: Adam Langley , =?utf-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= 
Thread-Topic: [TLS] An SCSV to stop TLS fallback.
Thread-Index: AQHO6jYL3OWisNV4bUWeT9bwHT1KGJo2nY0AgAAA2oCAABDBgIABFMQAgAEyeoCAAExnAIABUZeAgAjIOYCAAHtygIAAmWiAgAADqYCAAAINgIAANHGA
Date: Wed, 4 Dec 2013 23:05:43 +0000
Message-ID: 
References:            <529F7E9D.80302@elzevir.fr> 
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:ee31::2]
x-forefront-prvs: 0050CEFE70
x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(57704003)(377454003)(189002)(199002)(41574002)(24454002)(83322001)(69226001)(56776001)(54316002)(74706001)(31966008)(76482001)(81686001)(46102001)(47446002)(51856001)(63696002)(53806001)(85306002)(77982001)(49866001)(56816005)(59766001)(90146001)(81542001)(47976001)(83072001)(74876001)(79102001)(47736001)(87266001)(54356001)(50986001)(15975445006)(81816001)(76576001)(80022001)(80976001)(87936001)(19580395003)(76786001)(77096001)(65816001)(4396001)(2656002)(74502001)(76796001)(81342001)(74316001)(74662001)(74366001)(19580405001)(85852002)(33646001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB073; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "tls@ietf.org" 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 23:05:54 -0000

V2hhdCBwZXJjZW50YWdlIG9mIHRoZXNlIGNsaWVudCBmYWxsYmFjayBvcGVyYXRpb25zIHRoYXQg
YWN0dWFsIHVzZXJzIGJyb3dzZXJzIGFyZSBkb2luZyBpbiB0aGUgcmVhbCB3b3JsZCBhcmUgYmVp
bmcgdHJpZ2dlcmVkIGZvciByZWFzb25zICpvdGhlciogdGhhbiBhY3R1YWwgc2VydmVyIGltcGxl
bWVudGF0aW9uIGJ1Z3M/IEkgaW1hZ2luZSB0aGlzIGNvdWxkIGJlIGEgZGlmZmljdWx0IHRoaW5n
IHRvIG1lYXN1cmUuIEJ1dCBJIGNhbiBhbHNvIGltYWdpbmUgdGhlIG9idmlvdXMgY2xpZW50IGhl
dXJpc3RpY3MgKGlmIGl0IGZhaWxzLCB0cnkgYWdhaW4pIGNvdWxkIGVhc2lseSBiZSB0cmlnZ2Vy
ZWQgYnkgYSBidXN5IHNlcnZlciBvciBzaW1wbGUgcGFja2V0IGxvc3MuIENvdWxkbid0IHRoaXMg
cmVwcmVzZW50IGEgZnVsbCAxJSBvZiBjb25uZWN0aW9ucywgZXNwZWNpYWxseSBub3cgdGhhdCBz
byBtYW55IHVzZXJzIGFyZSBvbiBtb2JpbGUgZGV2aWNlcz8NCg0KU28gaWYgYSBmYWxsYmFjayBz
aXR1YXRpb24gd2FzIGEgc2xvdy1sb2FkaW5nIGxvdXN5IHBhZ2UgZXhwZXJpZW5jZSBiZWZvcmUs
IHdoYXQncyBpdCBnb2luZyB0byBiZSBhZnRlciBsZWdpdGltYXRlIHNlcnZlcnMgaW1wbGVtZW50
IHRoaXMgbG9naWM/IFdpbGwgc2VydmVycyBhY3RpdmVseSAqcmVmdXNlKiBsZWdpdGltYXRlIGNs
aWVudCdzIHJldHJ5IGNvbm5lY3Rpb25zPyBJZiBzbywgaXNuJ3QgdGhpcyBqdXN0IHRha2luZyBh
biBpbnRlcm1pdHRlbnQgc2xvdy1mYWlsdXJlIHNpdHVhdGlvbiBhbmQgY29udmVydGluZyBpdCB0
byBhbiBldmVuIHNsb3dlciBidXQgZ3VhcmFudGVlZCBpbnRlcm9wIGZhaWx1cmU/IElmIG5vdCwg
d2hhdCBnb29kIHdpbGwgZG93bmdyYWRlIHByb3RlY3Rpb24gbG9naWMgYmU/DQoNClRMUyAxLjIg
d2FzIGRlc2lnbmVkIHRvIG1pdGlnYXRlIHNvbWUgc2VyaW91cyBwb3RlbnRpYWwgYXR0YWNrcy4g
QkVBU1QgZGVtb25zdHJhdGVkIHRoZXNlIGF0dGFjayB2ZWN0b3JzIGNvdWxkIGJlIHByYWN0aWNh
bC4NCg0KV2UgbmVlZCB0byByZWNvZ25pemUgYWQtaG9jIGNsaWVudCBmYWxsYmFjayBoZXVyaXN0
aWMgZm9yIHdoYXQgaXQgaXM6IGEgc2VjdXJpdHkgdnVsbmVyYWJpbGl0eS4NCg0KVGhlcmVmb3Jl
LCBjbGllbnRzIE1VU1QgTk9UIGF1dG8tZG93bmdyYWRlLg0KDQpUaGVyZWZvcmUsIGJyb2tlbiBz
ZXJ2ZXJzIGFuZCBtaWRkbGVib3hlcyBuZWVkIHRvIGNsZWFuIHVwIHRoZWlyIGFjdCBvciBHVEZP
Lg0KDQpUaGlzIHdhcyBhbHdheXMgY2xlYXIgdG8gYW55b25lIGNvbnNpZGVyaW5nIGl0IGZyb20g
YSBwcm90b2NvbCBzZWN1cml0eSBhbmdsZS4gQnV0IHRoZSBzdHJvbmcgZGVzaXJlIGZvciBpbnRl
cm9wZXJhYmlsaXR5IGFuZCB0aGUgYWJzZW5jZSBvZiBkb2N1bWVudGVkIGF0dGFja3MgaW4gdGhl
IDIwMDAncyBtYWRlIGl0IGhhcmQgdG8gYXJndWUgZnJvbSBwcmluY2lwbGUuDQoNCkRvIHdlIG5l
ZWQgYW4gUkZDIGEnIGxhIDYxNzYgdG8gZ2l2ZSBzZWN1cml0eS1taW5kZWQgZGV2ZWxvcGVycyBh
biBleHBsaWNpdCBhcmd1bWVudCBmcm9tIGF1dGhvcml0eT8NCg0KLSBNYXJzaA0KDQpQLlMuIEkg
YWRtaXQgdG8gYmVpbmcgc29tZXdoYXQgc2tlcHRpY2FsIHdoZW4gUkZDIDYxNzYgd2FzIGJlaW5n
IHByb3Bvc2VkLiBCdXQgSSBtZW50aW9uZWQgaXQgaW4gYSBtZWV0aW5nIHRoZSBvdGhlciBkYXkg
YW5kIHRoZXJlIHdlcmUgbGl0ZXJhbGx5IG5vZHMgb2YgdW5kZXJzdGFuZGluZyBhbGwgYXJvdW5k
IHRoZSB0YWJsZS4gVGhhbmtzIQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t
OiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkYW0gTGFu
Z2xleQ0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciA0LCAyMDEzIDExOjIwIEFNDQpUbzogTWFu
dWVsIFDDqWdvdXJpw6ktR29ubmFyZA0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtU
TFNdIEFuIFNDU1YgdG8gc3RvcCBUTFMgZmFsbGJhY2suDQoNCk9uIFdlZCwgRGVjIDQsIDIwMTMg
YXQgMjoxMiBQTSwgTWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZCA8bXBnQGVsemV2aXIuZnI+IHdy
b3RlOg0KPiBVbmxlc3MgSSdtIG1pc3Rha2VuLCB0aGUgcHJvYmxlbSBUTFNfRkFMTEJBQ0tfU0NT
ViB0cmllcyB0byBhZHJlc3MgaXMgDQo+IG5vdCBzZXJ2ZXJzIHRoYXQgZG9uJ3QgaW1wbGVtZW50
IHZlcnNpb24gbmVnb3RpYXRpb24gY29ycmVjdGx5LCBidXQgDQo+IE1JVE0gYWN0aXZlbHkgZG9p
bmcgYSBkb3duZ3JhZGUgYXR0YWNrIChhbmQgZmF1bHR5IG1pZGRsZWJveGVzLCB3aGljaCBoYXZl
IHRoZSBzYW1lIGVmZmVjdCkuDQoNCkkgdGhpbmsgdGhlIGNoYWluIG9mIHNhZG5lc3MgZ29lcyBs
aWtlIHRoaXM6DQoNCjEpIFNvbWUgc2VydmVycyBkb24ndCBpbXBsZW1lbnQgdmVyc2lvbiBuZWdv
dGlhdGlvbiBjb3JyZWN0bHksIG9yIGhhdmUgb3RoZXIgYnVncyB0aGF0IGhhcHBlbiB0byBiZSBz
b2x2ZWQgYnkgdXNpbmcgU1NMdjMuDQoyKSBUaGVyZWZvcmUgc29tZSBjbGllbnRzIGltcGxlbWVu
dCBmYWxsYmFjaw0KMykgVGhlcmVmb3JlIGF0dGFja2VycyBjYW4gdHJpZ2dlciBmYWxsYmFjayBl
dmVuIHdpdGggY29ycmVjdCBzZXJ2ZXJzLg0KDQpUaGUgTUlUTSBwcm94aWVzIHRoYXQgYWxzbyBo
YWQgZG93bmdyYWRlIGJ1Z3MgY2F1c2VkIGlzc3VlcyB3aXRoIGEgQ2hyb21lIGV4cGVyaW1lbnQg
d2hlcmUgd2UgcmVtb3ZlZCBTU0x2MyBmYWxsYmFjayBmb3IgR29vZ2xlIHByb3BlcnRpZXMgYmVj
YXVzZSBpdCBsb29rZWQsIHRvIHRoZSBjbGllbnQsIGxpa2UgYW4gYXR0YWNrLiBCdXQsIHNpbmNl
IGl0J3MgYSBNSVRNIHByb3h5LCBpdCdzIGFuIGF0dGFjayB0aGF0IHRoZSB1c2VyIGhhcyBhdXRo
b3Jpc2VkLg0KDQoNCkNoZWVycw0KDQpBR0wNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmcNCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo=

From stebila@qut.edu.au  Wed Dec  4 15:38:47 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A401ADF66 for ; Wed,  4 Dec 2013 15:38:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.498
X-Spam-Level: 
X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 I4x4KnM2QwLa for ; Wed,  4 Dec 2013 15:38:45 -0800 (PST)
Received: from QUTEXEDGE05.qut.edu.au (qutexedge05.qut.edu.au [131.181.191.22]) by ietfa.amsl.com (Postfix) with ESMTP id C32081ADF59 for ; Wed,  4 Dec 2013 15:38:43 -0800 (PST)
Received: from QUTEXHUB04.qut.edu.au (131.181.186.100) by qutexedge05.qut.edu.au (131.181.191.22) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 5 Dec 2013 09:38:38 +1000
Received: from QUTEXMBX01.qut.edu.au ([131.181.107.108]) by QUTEXHUB04.qut.edu.au ([131.181.186.100]) with mapi; Thu, 5 Dec 2013 09:38:12 +1000
From: Douglas Stebila 
To: "tls@ietf.org" 
Date: Thu, 5 Dec 2013 09:36:28 +1000
Thread-Topic: [TLS] An SCSV to stop TLS fallback.
Thread-Index: AQHO6jYL3OWisNV4bUWeT9bwHT1KGJo2nY0AgAAA2oCAABDBgIABFMQAgAEyeoCAAExnAIABUZeAgAjIOYCAAHtygIAAmWiAgAADqYCAAAINgIAANHGAgAATRUE=
Message-ID: 
References:            <529F7E9D.80302@elzevir.fr> , 
In-Reply-To: 
Accept-Language: en-US, en-AU
Content-Language: en-CA
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 04 Dec 2013 23:38:48 -0000

Does anyone on the list know of an example website where one can observe a =
potentially attackable TLS fallback?

Douglas

________________________________________
From: TLS [tls-bounces@ietf.org] On Behalf Of Marsh Ray [maray@microsoft.co=
m]
Sent: December 5, 2013 09:05
To: Adam Langley; Manuel P=E9gouri=E9-Gonnard
Cc: tls@ietf.org
Subject: Re: [TLS] An SCSV to stop TLS fallback.

What percentage of these client fallback operations that actual users brows=
ers are doing in the real world are being triggered for reasons *other* tha=
n actual server implementation bugs? I imagine this could be a difficult th=
ing to measure. But I can also imagine the obvious client heuristics (if it=
 fails, try again) could easily be triggered by a busy server or simple pac=
ket loss. Couldn't this represent a full 1% of connections, especially now =
that so many users are on mobile devices?

So if a fallback situation was a slow-loading lousy page experience before,=
 what's it going to be after legitimate servers implement this logic? Will =
servers actively *refuse* legitimate client's retry connections? If so, isn=
't this just taking an intermittent slow-failure situation and converting i=
t to an even slower but guaranteed interop failure? If not, what good will =
downgrade protection logic be?

TLS 1.2 was designed to mitigate some serious potential attacks. BEAST demo=
nstrated these attack vectors could be practical.

We need to recognize ad-hoc client fallback heuristic for what it is: a sec=
urity vulnerability.

Therefore, clients MUST NOT auto-downgrade.

Therefore, broken servers and middleboxes need to clean up their act or GTF=
O.

This was always clear to anyone considering it from a protocol security ang=
le. But the strong desire for interoperability and the absence of documente=
d attacks in the 2000's made it hard to argue from principle.

Do we need an RFC a' la 6176 to give security-minded developers an explicit=
 argument from authority?

- Marsh

P.S. I admit to being somewhat skeptical when RFC 6176 was being proposed. =
But I mentioned it in a meeting the other day and there were literally nods=
 of understanding all around the table. Thanks!


-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Adam Langley
Sent: Wednesday, December 4, 2013 11:20 AM
To: Manuel P=E9gouri=E9-Gonnard
Cc: tls@ietf.org
Subject: Re: [TLS] An SCSV to stop TLS fallback.

On Wed, Dec 4, 2013 at 2:12 PM, Manuel P=E9gouri=E9-Gonnard  wrote:
> Unless I'm mistaken, the problem TLS_FALLBACK_SCSV tries to adress is
> not servers that don't implement version negotiation correctly, but
> MITM actively doing a downgrade attack (and faulty middleboxes, which hav=
e the same effect).

I think the chain of sadness goes like this:

1) Some servers don't implement version negotiation correctly, or have othe=
r bugs that happen to be solved by using SSLv3.
2) Therefore some clients implement fallback
3) Therefore attackers can trigger fallback even with correct servers.

The MITM proxies that also had downgrade bugs caused issues with a Chrome e=
xperiment where we removed SSLv3 fallback for Google properties because it =
looked, to the client, like an attack. But, since it's a MITM proxy, it's a=
n attack that the user has authorised.


Cheers

AGL
_______________________________________________
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 yngve@spec-work.net  Wed Dec  4 16:34:09 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48221AE1D5 for ; Wed,  4 Dec 2013 16:34:09 -0800 (PST)
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 uD5Imu_GgoCr for ; Wed,  4 Dec 2013 16:34:07 -0800 (PST)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDDA1AE1D1 for ; Wed,  4 Dec 2013 16:34:06 -0800 (PST)
Received: from 47.70.202.84.customer.cdi.no ([84.202.70.47]:54359 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VoMtH-0003w5-61 for tls@ietf.org; Thu, 05 Dec 2013 01:34:03 +0100
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: tls@ietf.org
References:            <529F7E9D.80302@elzevir.fr>   
Date: Thu, 05 Dec 2013 01:33:57 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" 
Message-ID: 
In-Reply-To: 
User-Agent: Opera Mail/12.15 (Win32)
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 00:34:09 -0000

On Thu, 05 Dec 2013 00:36:28 +0100, Douglas Stebila   
wrote:

> Does anyone on the list know of an example website where one can observe  
> a potentially attackable TLS fallback?

You could have a look at https://www.bankofthewest.com ; it is a TLS 1.0  
server that does not tolerate TLS 1.1 or 1.2. Curiously enough, it  
tolerates the version bytes 4.1 and negotiates TLS 1.0

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

From yngve@spec-work.net  Wed Dec  4 16:34:10 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED5F1AE1D1 for ; Wed,  4 Dec 2013 16:34:10 -0800 (PST)
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 2qi1zTZVACwh for ; Wed,  4 Dec 2013 16:34:07 -0800 (PST)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 631DB1AE1D4 for ; Wed,  4 Dec 2013 16:34:06 -0800 (PST)
Received: from 47.70.202.84.customer.cdi.no ([84.202.70.47]:54359 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VoMtH-0003w5-CH for tls@ietf.org; Thu, 05 Dec 2013 01:34:03 +0100
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: tls@ietf.org
References:            <529F7E9D.80302@elzevir.fr>  
Date: Thu, 05 Dec 2013 01:33:59 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" 
Message-ID: 
In-Reply-To: 
User-Agent: Opera Mail/12.15 (Win32)
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 00:34:10 -0000

On Thu, 05 Dec 2013 00:05:43 +0100, Marsh Ray  wrote:

> What percentage of these client fallback operations that actual users  
> browsers are doing in the real world are being triggered for reasons  
> *other* than actual server implementation bugs? I imagine this could be  
> a difficult thing to measure. But I can also imagine the obvious client  
> heuristics (if it fails, try again) could easily be triggered by a busy  
> server or simple packet loss. Couldn't this represent a full 1% of  
> connections, especially now that so many users are on mobile devices?

It is definitely a possibility.

One part of Opera's (v12 and before) logic regarding fallbacks was to fall  
back if the connection took too long to establish after the handshake had  
started, since some problematic servers would never respond if they did  
not like the handshake. IIRC the trigger time was 6 or 10 seconds.

> So if a fallback situation was a slow-loading lousy page experience  
> before, what's it going to be after legitimate servers implement this  
> logic? Will servers actively *refuse* legitimate client's retry  
> connections? If so, isn't this just taking an intermittent slow-failure  
> situation and converting it to an even slower but guaranteed interop  
> failure? If not, what good will downgrade protection logic be?
>
> TLS 1.2 was designed to mitigate some serious potential attacks. BEAST  
> demonstrated these attack vectors could be practical.
>
> We need to recognize ad-hoc client fallback heuristic for what it is: a  
> security vulnerability.
>
> Therefore, clients MUST NOT auto-downgrade.

The main point of contention is how to accomplish this without "breaking  
the web" and how to do this in a fashion that improves security quickly.

The SCSV proposal very likely will not "break the web", but my objection  
is that it will require updates to all the servers, and not just the  
clients, and thus take too long to deploy (case in point: 4 years after  
the Renego problem was discovered, 20% of servers are still not patched).  
Given that. 14 years after TLS 1.0 was released, about 1% of servers still  
only support SSL v3. I do not have high hopes of having SCSVs fully  
deployed in 15 years (unless client vendors decide to, or have to, "break  
the web").

My suggestion have been to update the clients to refuse to use fallback  
when connecting to servers that implement the Renego patch. This have the  
benefit of using a proxy for correct version negotiation, which is already  
deployed on a majority of servers. The drawback of my proposal is that the  
proxy indication is not perfect; there is a small fraction of patched  
servers that are version and/or extension intolerant, and there is a much  
larger fraction of servers that are version intolerant for whatever  
version bytes TLS 1.3+ will use. Some will call the first group as  
"breaking the web", while most will probably agree that the second can  
definitely be called "breaking the web".

The question is, if client vendors agree to "bull through" and refuse to  
fall back, will the server vendors and web site operators fix their  
implementations, and if so, how quickly? The best option in such a  
scenario would probably be a coordinated same-day release  (alternatively  
flipping a flag) of updated clients, particularly browsers, so that web  
sites cannot use the "switch browser" "advice" for fixing the "browser  
bug". (Flipping a flag might be the better option, since this will allow  
the updated browsers to gain a sufficiently large marketshare before  
changing the behavior)

What to do comes down to the answers to a few questions:

  - How much website breakage will be tolerated for a fix? (keep in mind  
that the fix will almost certainly require the client or server to abort a  
connection that cannot be started without a fallback, if not, what's the  
use?)
  - How secure do the vendors, website administrators and users want the  
web to be?
  - How quickly is it desirable to obtain that level of security?

The answers to each of these affect the answer to the others, so the trick  
will be to find a useful compromise that does not compromise security.

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

From cloos@jhcloos.com  Wed Dec  4 17:14:50 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020D21ADFD1 for ; Wed,  4 Dec 2013 17:14:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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.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 0eQO2ab6DAwu for ; Wed,  4 Dec 2013 17:14:47 -0800 (PST)
Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id BE8601ADFB0 for ; Wed,  4 Dec 2013 17:14:47 -0800 (PST)
Received: by ore.jhcloos.com (Postfix, from userid 10) id DEAD31DEB3; Thu,  5 Dec 2013 01:14:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1386206083; bh=FzCmjnJKecPbemkFlhEJdeLC4j1nBp0Ik3V46zRYzz8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=N6UW1+jZtN34T8Rx0qukoX3ljDeLsud4RtSFtLzKroUlj04Ao8UPreMurNdsQ73Wd GHVKC6d2wIh2wX5p+1CTnDHaHkHpdpvwFWR2r9N6lUaGCUMRlHtW4POF1ZD974LkUD sQBgb9KgfitK+VT7LrVGVHhVWPkidj+V7I8CdCzriqg==
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 2C3D460027; Thu,  5 Dec 2013 00:52:34 +0000 (UTC)
From: James Cloos 
To: Douglas Stebila 
In-Reply-To:  (Douglas Stebila's message of "Thu, 5 Dec 2013 09:36:28 +1000")
References:            <529F7E9D.80302@elzevir.fr>   
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2013 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Wed, 04 Dec 2013 19:52:34 -0500
Message-ID: 
Lines: 12
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:131205:stebila@qut.edu.au::hWhETYUI5kP0xPzh:000000000000000000000000000000000000000000R2o5i
X-Hashcash: 1:30:131205:"tls\@ietf.org"::nbptrr1NvC39GLVP:0yXVRR
X-Hashcash: 1:30:131205:tls@ietf.org::SZa3LEg3QIkMvXIL:0000Ekqgr
Cc: "tls@ietf.org" 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 01:14:50 -0000

>>>>> "DS" == Douglas Stebila  writes:

DS> Does anyone on the list know of an example website where one can
DS> observe a potentially attackable TLS fallback?

I do not know the extent to which it is attackable, but https://archive.org
(aka www.archive.org) only works with ssl/3.0.  TLS-only clients cannot
connect thereto.

-JimC
--
James Cloos          OpenPGP: 1024D/ED7DAEA6

From yngve@spec-work.net  Wed Dec  4 18:15:57 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39C81ADFFC for ; Wed,  4 Dec 2013 18:15:57 -0800 (PST)
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 tm66sZLMohAU for ; Wed,  4 Dec 2013 18:15:55 -0800 (PST)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2B12C1ADF7E for ; Wed,  4 Dec 2013 18:15:54 -0800 (PST)
Received: from 47.70.202.84.customer.cdi.no ([84.202.70.47]:56041 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VoOTm-0006Gj-Ud for tls@ietf.org; Thu, 05 Dec 2013 03:15:50 +0100
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: tls@ietf.org
References:            <529F7E9D.80302@elzevir.fr>    
Date: Thu, 05 Dec 2013 03:15:45 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" 
Message-ID: 
In-Reply-To: 
User-Agent: Opera Mail/12.15 (Win32)
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 02:15:57 -0000

On Thu, 05 Dec 2013 01:52:34 +0100, James Cloos  wrote:

>>>>>> "DS" == Douglas Stebila  writes:
>
> DS> Does anyone on the list know of an example website where one can
> DS> observe a potentially attackable TLS fallback?
>
> I do not know the extent to which it is attackable, but  
> https://archive.org
> (aka www.archive.org) only works with ssl/3.0.  TLS-only clients cannot
> connect thereto.

This site may be SSL v3.0-only, but it is version and extension tolerant  
up to at least version bytes 3.4, as well as for 4.1. It is also Renego  
patched, and AFAICT support SNI and ECDHE_RSA. Given the latter two, I  
wonder if the server is actually able to support at least TLS 1.0, but  
that it have been disabled somehow, perhaps due to an old configuration  
setting that only specifies SSL v3 as enabled (perhaps in order to disable  
SSL v2).

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

From p.gutmann@auckland.ac.nz  Wed Dec  4 19:24:31 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B621AE21A for ; Wed,  4 Dec 2013 19:24:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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.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 2FIhzfKWxQV4 for ; Wed,  4 Dec 2013 19:24:28 -0800 (PST)
Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.125.243]) by ietfa.amsl.com (Postfix) with ESMTP id 51A121AE013 for ; Wed,  4 Dec 2013 19:24:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1386213866; x=1417749866; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=k4b/P40Fd+UicYK950yN9UxuZ51ZBtrxh35LJavyvoU=; b=AaNICr6lDDYLwlZAAAJKJtZjTBHUu5XI1E79aDrA5STZiuDCiMkE1jk8 q6J/zh0TVb7EUZpQX6ulSgMCPqfige9Q1W7iFO1TsrJSOU9LWWbrGHKKJ KH6GToui7/ADNva0rp6pAxWQT4swtULYPcFM1WEP8DGcqiLEuLWZ++3Q9 A=;
X-IronPort-AV: E=Sophos;i="4.93,830,1378814400"; d="scan'208";a="297740666"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 05 Dec 2013 16:24:22 +1300
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.143]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 16:24:21 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Encrypt-then-MAC again (was Re: padding bug)
Thread-Index: Ac7xaX0Qys0s6wXERx+wmf2KKaA0kQ==
Date: Thu, 5 Dec 2013 03:24:21 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7365423E10@uxcn10-6.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
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 03:24:31 -0000

Eric Rescorla  writes:=0A=
=0A=
>This topic was discussed at the TLS WG meeting in Vancouver (since you =0A=
>declined to attend, =0A=
=0A=
So by cleverly choosing a forum that you knew I couldn't attend (and that =
=0A=
others who were interested in it, e.g. WG members from Europe, couldn't =0A=
attend either) you managed to manufacture consent and perpetuate your =0A=
refusal to address the issue.  =0A=
=0A=
In any case the WG consists of people on this mailing list, not a select =
=0A=
few folks in some back-room in Vancouver.=0A=
=0A=
Peter.=0A=

From p.gutmann@auckland.ac.nz  Wed Dec  4 19:35:42 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C335A1AE01D for ; Wed,  4 Dec 2013 19:35:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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.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 dH_funVUcVdj for ; Wed,  4 Dec 2013 19:35:39 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id EDE6C1AE01B for ; Wed,  4 Dec 2013 19:35:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1386214536; x=1417750536; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=HHzXzLUiezbYFjsMZScNuYa/BCTxIgH5E7SGFVXr728=; b=msxCwOTRWoLj6p8kTgIHbblZoZL8EJoFEU/WfN1KExcSohSjkJf6UyAe nSnZN6w8qtCzx8lS6mKAn6BQwpYBKfi/mznR1CUna6DQzQrzoygm3CR9o Mko09i4pRocZszNeuP+l9oS4zravleCWenzO9bzpf1pQKFavV1R50EoRi U=;
X-IronPort-AV: E=Sophos;i="4.93,830,1378814400"; d="scan'208";a="225812388"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 05 Dec 2013 16:35:35 +1300
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.143]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 16:35:34 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Encrypt-then-MAC again (was Re: padding bug)
Thread-Index: Ac7xaw59XkIZ/XYYTNCsDtR42mtKbQ==
Date: Thu, 5 Dec 2013 03:35:34 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7365423E23@uxcn10-6.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
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 03:35:43 -0000

Martin Rex  writes:=0A=
=0A=
>TLSv1.2 is a royal PITA for TLS clients, because it requires a reconnect=
=0A=
>fallback facility to be implemented by ***EVERY*** application caller clie=
nt =0A=
>on top of TLS, ***PLUS*** every application caller will have to memorize t=
he =0A=
>fallback for every destination or the latency will be a royal pain for eve=
ry =0A=
>new handshake after the TLS session expires from the client-side TLS sessi=
on =0A=
>cache (when client-side session caching is used at all.  =0A=
=0A=
It's a PITA in general because it introduces a bunch of unexplained and mor=
e=0A=
or less arbitrary restrictions and silly-walk requirements (e.g. if you do=
=0A=
X with algorithm Y then you also need to do Z) which have no effect except =
to =0A=
break interoperability.  Things mostly work at the moment because by mutual=
=0A=
unspoken consensus implementers ignore some of the sillier requirements, or=
=0A=
because there's a common mode like using SHA-256 everywhere that seems to =
=0A=
work OK for all implementations.  At some point in the future though this i=
s =0A=
going to cause headaches when other implementations that don't know how to=
=0A=
interpret the spec in order to make things work come along.=0A=
=0A=
Peter.=

From p.gutmann@auckland.ac.nz  Wed Dec  4 20:42:09 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC3E1ADFD9 for ; Wed,  4 Dec 2013 20:42:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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.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 Vd6x42In4wOd for ; Wed,  4 Dec 2013 20:42:05 -0800 (PST)
Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.125.243]) by ietfa.amsl.com (Postfix) with ESMTP id C38801AE173 for ; Wed,  4 Dec 2013 20:42:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1386218522; x=1417754522; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ISZK0V//fKvARYadyibSVMrE0oZgnBAVgfK/PBq7Ra0=; b=NUOtAm929HCDWXk9aJuQg9rM7/aCx999VaCNxUgiDe6i2SuTrAFuP9ux ipK1ob3dlysPYORTVjiez0XzI5AviNew2G5O0n4jHAiPNivftzPdQHSEs hoEqKP1Pim97Uiu8+4GcWl++I1nLrksdeJFJxErrRar0gGdANtddmTqTr 4=;
X-IronPort-AV: E=Sophos;i="4.93,830,1378814400"; d="scan'208";a="297760217"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 05 Dec 2013 17:41:58 +1300
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.143]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 17:41:58 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Encrypt-then-MAC again (was Re: padding bug)
Thread-Index: Ac7xdFSSdqqcHS6sRtyDMubiiswmoA==
Date: Thu, 5 Dec 2013 04:41:57 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7365423E95@uxcn10-6.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
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 04:42:09 -0000

Martin Rex  writes:=0A=
=0A=
>Peter's proposal changes AtE to EtA, but does not currently address the =
=0A=
>predictable IV for SSLv3 & TLSv1.0.  As it turns out, EtA will not protect=
 =0A=
>from BEAST, because it is "generically" secure only against decryption =0A=
>oracles.  BEAST was exploiting an _encryption_ oracle.=0A=
=0A=
The idea was to fix as much as possible with the least overhead possible.  =
In=0A=
my code I had to change four lines of code (exclusing the negotiate-EtA bit=
s,=0A=
which mostly involve changing some lookup tables), which is about as low-=
=0A=
impact as you can get.  I can certainly add explicit-IV, but since you get=
=0A=
that in TLS 1.1 anyway it didn't seem like a good idea to start messing aro=
und=0A=
with other aspects of the protocol.=0A=
=0A=
Peter.=0A=

From p.gutmann@auckland.ac.nz  Wed Dec  4 21:06:23 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FC31AE350 for ; Wed,  4 Dec 2013 21:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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.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 u3QihsfOxCS8 for ; Wed,  4 Dec 2013 21:06:21 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 902301AE02F for ; Wed,  4 Dec 2013 21:06:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1386219976; x=1417755976; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=VNLZGeTVJ0WRJ/IvE5VcxCJbwOThyR0INEYXo+ubpHI=; b=h6AZEXusb1YkQLHhNzao19ei2/SAxlUecodAbWDU2esxrOmDgBVeb2NK QZoOo//ozzYMiXbnaH7EkIEMWtR83XRT3+jfzDFqyJcjjduSPfmNRg1vF bEsqYWoe+cnhaG0s1UoKCyKxgNiQ91lJnrhhPL4lPPxUD3vINxNlmCOpR c=;
X-IronPort-AV: E=Sophos;i="4.93,830,1378814400"; d="scan'208";a="225819660"
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; 05 Dec 2013 18:06:15 +1300
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.143]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 18:06:13 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Encrypt-then-MAC again (was Re: padding bug)
Thread-Index: Ac7xd7g3lq59mp59T26lRXCd24M6Hg==
Date: Thu, 5 Dec 2013 05:06:13 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7365423EC2@uxcn10-6.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
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 05:06:23 -0000

Martin Rex  writes:=0A=
=0A=
>I'm from the "don't-fix-it-if-it-ain't-broken" camp. And the less code nee=
ds =0A=
>to be changed to adopt some useful feature, the more likely you will see i=
t =0A=
>being adopted for patches/maintenance. I have seen *ZERO* compelling reaso=
n =0A=
>for switching to encrypt-then-mac in TLS. =0A=
=0A=
Uhh... what?  How have you missed ten years of attacks on TLS that take =0A=
advantage of MtE?=0A=
=0A=
Peter.=0A=

From trevp@trevp.net  Wed Dec  4 21:51:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9AB1AE1F2 for ; Wed,  4 Dec 2013 21:51:41 -0800 (PST)
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 3Wii35IN3O8C for ; Wed,  4 Dec 2013 21:51:39 -0800 (PST)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 97D7F1AE085 for ; Wed,  4 Dec 2013 21:51:39 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id z2so7716326wiv.6 for ; Wed, 04 Dec 2013 21:51:35 -0800 (PST)
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=bM0zzoxA4+u8wjNQP+uDGiHis7tK40+tgLAJ7T3Im9E=; b=HjGTpoopmN7sQ6eP2rwIJweHNdVa7mIqEAi1K5pACi2xgrYTbcL3NaYYuoNsBVc4Et 5M6hEm6/dL6pRrtSesIKdGotOi9Zmly4zKsAAQ4By3XDkrMIizibcpjlR4G9YeOlLKWJ UMtNpdpbNAMCp93vkccKmVqhpGhU3mWCm29Tiqs7JQ42KzTKwAabOYZ5rbc1WhpJZZkp sjwCC6JMVTFjeAnAqonG+itPhbiOLnzIp3ib30NHBTdpPBPGTQ+q6A+aTHMycGPwyp4F Jh7trfOclT/hBl0CrnovkSHcq5xfMcMNulWdKkm0Ljpsd0rN5ZAkyjuU4UsOUKR12FJL PI4Q==
X-Gm-Message-State: ALoCoQm0dtVwzp0QSPN+1UA/rPmtW5JIY63/iORMe1rH8gLdPKUkw+ipe9sIXlvwJlIzJYR0e8y/
MIME-Version: 1.0
X-Received: by 10.194.104.66 with SMTP id gc2mr5431350wjb.75.1386222695924; Wed, 04 Dec 2013 21:51:35 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Wed, 4 Dec 2013 21:51:35 -0800 (PST)
X-Originating-IP: [166.137.187.58]
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7365423E95@uxcn10-6.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C7365423E95@uxcn10-6.UoA.auckland.ac.nz>
Date: Wed, 4 Dec 2013 21:51:35 -0800
Message-ID: 
From: Trevor Perrin 
To: Peter Gutmann 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" 
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 05:51:41 -0000

I'd like to add a vote for Peter's draft, along with (I believe)
Wan-Teh, Robert Ransom, Juho V=E4h=E4-Herttua, and others.

Some small objections have been raised which I believe can be countered:

 * Nikos prefers Mac-then-Encrypt over the reverse, but otherwise
supports this. [1]

 * Adam Langley has "no objection" to this, but prefers to focus on
AES-GCM and ChaCha20 [2].  Browsers are very concerned with speed, so
it's not surprising they prefer CTR-and-polynomial-MAC ciphersuites.
However, TLS is used places besides the browser, and I suspect many of
the smaller TLS libraries (such as those by Nikos, Peter, or myself)
would prefer smaller code changes.  Also, Peter's draft easily
upgrades security for all versions of TLS, and less-common
ciphersuites like TLS-SRP and TLS-PSK.


Trevor


[1] http://www.ietf.org/mail-archive/web/tls/current/msg10736.html
[2] http://www.ietf.org/mail-archive/web/tls/current/msg09826.html

From watsonbladd@gmail.com  Wed Dec  4 21:53:42 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABE21AE1F2 for ; Wed,  4 Dec 2013 21:53:42 -0800 (PST)
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 B5EOPS8wPGpM for ; Wed,  4 Dec 2013 21:53:40 -0800 (PST)
Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0561AE085 for ; Wed,  4 Dec 2013 21:53:40 -0800 (PST)
Received: by mail-wg0-f53.google.com with SMTP id k14so13751502wgh.32 for ; Wed, 04 Dec 2013 21:53:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gE3HSmjmV81dC4FJBCbqUXsojm8koU4LFh24EaSzBp0=; b=bvyhJKBXbhkisfnIn38s+wftWHNTbP36USFUb4an7+6d5N9Kyev9FD/sAlGMQGd5dr Q2yFrLpts+0ubtexg3uR4NXQSe26y+IZj3VcUquvgqxkj4jbdGjaMCnO9TnwSo2OY90x uof7s/8IN39lmkS5ca9aEa8drLCKUYHlCn36jG6X4xsI93igHXW5GoEcxq0Rhg4sBAFR LjXMuGnSQ19G1UiQLdIGPqy9KWx0Z2c5UVi9AFOwlqI6BibCSPl7AZlDp5x10KQCEYbz i0B1SF6g9E9tqnzFoo7d7fVDCE5aeT+Q1HUTwM0122r3ge6K0yevtrzvTYiHWCF/lRVT h8lA==
MIME-Version: 1.0
X-Received: by 10.194.94.167 with SMTP id dd7mr15631097wjb.43.1386222816608; Wed, 04 Dec 2013 21:53:36 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Wed, 4 Dec 2013 21:53:36 -0800 (PST)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C7365423E95@uxcn10-6.UoA.auckland.ac.nz> 
Date: Wed, 4 Dec 2013 21:53:36 -0800
Message-ID: 
From: Watson Ladd 
To: Trevor Perrin 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" , Peter Gutmann 
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 05:53:42 -0000

On Wed, Dec 4, 2013 at 9:51 PM, Trevor Perrin  wrote:
> I'd like to add a vote for Peter's draft, along with (I believe)
> Wan-Teh, Robert Ransom, Juho V=C3=A4h=C3=A4-Herttua, and others.
>
> Some small objections have been raised which I believe can be countered:
>
>  * Nikos prefers Mac-then-Encrypt over the reverse, but otherwise
> supports this. [1]
>
>  * Adam Langley has "no objection" to this, but prefers to focus on
> AES-GCM and ChaCha20 [2].  Browsers are very concerned with speed, so
> it's not surprising they prefer CTR-and-polynomial-MAC ciphersuites.
> However, TLS is used places besides the browser, and I suspect many of
> the smaller TLS libraries (such as those by Nikos, Peter, or myself)
> would prefer smaller code changes.  Also, Peter's draft easily
> upgrades security for all versions of TLS, and less-common
> ciphersuites like TLS-SRP and TLS-PSK.
AGL's opposition was mine, but given the reasoning Trevor presents I
would like to put my
vote behind Peter's draft.
>
>
> Trevor
>
>
> [1] http://www.ietf.org/mail-archive/web/tls/current/msg10736.html
> [2] http://www.ietf.org/mail-archive/web/tls/current/msg09826.html
> _______________________________________________
> 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 mrex@sap.com  Wed Dec  4 22:06:37 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305C51AE1F7 for ; Wed,  4 Dec 2013 22:06:37 -0800 (PST)
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 ttWTihB5T22X for ; Wed,  4 Dec 2013 22:06:34 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2A72A1AE36D for ; Wed,  4 Dec 2013 22:06:34 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rB566MNf003117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Dec 2013 07:06:22 +0100 (MET)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7365423EC2@uxcn10-6.UoA.auckland.ac.nz>
To: Peter Gutmann 
Date: Thu, 5 Dec 2013 07:06:21 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20131205060621.F23521AB26@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "" 
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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, 05 Dec 2013 06:06:37 -0000

Peter Gutmann wrote:
> Martin Rex  writes:
> 
> >I'm from the "don't-fix-it-if-it-ain't-broken" camp. And the less code needs 
> >to be changed to adopt some useful feature, the more likely you will see it 
> >being adopted for patches/maintenance. I have seen *ZERO* compelling reason 
> >for switching to encrypt-then-mac in TLS. 
> 
> Uhh... what?  How have you missed ten years of attacks on TLS that take 
> advantage of MtE?

TLS using pad-mac-encrypt is proven secure and that mac-pad-encrypt
is a going to provide an attack surface was clearly pointed out by 
Serge Vaudenay in 2001.

This could have been fixed in TLSv1.1 (2006), but was ignored.
The attacks that were demonstrated were in the ballpark of what
was predicted in 2001.


The fragility of GCM worries me personally much more than the
attack surface of mac-pad-encrypt, e.g.

  Cycling Attacks on GCM, GHASH and Other Polynomial MACs and Hashes
  Markku-Juhani O. Saarinen
  http://eprint.iacr.org/2011/202.pdf


-Martin

From mpg@elzevir.fr  Thu Dec  5 00:51:46 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534DB1ACCD8 for ; Thu,  5 Dec 2013 00:51:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.251
X-Spam-Level: 
X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-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 WCm2GUwi3cfg for ; Thu,  5 Dec 2013 00:51:44 -0800 (PST)
Received: from mordell.elzevir.fr (mordell.elzevir.fr [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by ietfa.amsl.com (Postfix) with ESMTP id 814B21AD739 for ; Thu,  5 Dec 2013 00:51:44 -0800 (PST)
Received: from thue.elzevir.fr (unknown [IPv6:2a01:e35:8a5d:80b0:be5f:f4ff:fe2c:95bc]) by mordell.elzevir.fr (Postfix) with ESMTPS id 8EA9C160BF for ; Thu,  5 Dec 2013 09:51:40 +0100 (CET)
Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 6090B27197 for ; Thu,  5 Dec 2013 09:51:39 +0100 (CET)
Message-ID: <52A03E9A.4080507@elzevir.fr>
Date: Thu, 05 Dec 2013 09:51:38 +0100
From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
To: tls@ietf.org
References:            <529F7E9D.80302@elzevir.fr>  
In-Reply-To: 
X-Enigmail-Version: 1.6
OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 08:51:46 -0000

On 05/12/2013 00:05, Marsh Ray wrote:
> So if a fallback situation was a slow-loading lousy page experience
> before, what's it going to be after legitimate servers implement this
> logic? Will servers actively *refuse* legitimate client's retry
> connections? If so, isn't this just taking an intermittent
> slow-failure situation and converting it to an even slower but
> guaranteed interop failure? If not, what good will downgrade
> protection logic be?
> 
It seems to me Adam already answered this argument, and his point was that
browsers don't retry plain HTTP connexions anyway, so the situation with
TLS_FALLBACK_SCSV with respect to intermittent failures situations will not be
very different from what it is with HTTP: the browser will show a failure page
and the user will hit the "retry" button.

So, it's not turning an intermittent failure into a permanent one: it's merely
turning an intermittent failure that may not have been visible to the user in
case a silent fallback into an intermittent failure visible to the user.

The only drawback is, as you note, the failure will be slower, compared to what
it would be without any fallback attempt. So the question is, which is worse:
1. Slowing down the display of an error message in case of intermittent failures
with a legitimate and compliant server (the situation with fallback and
TLS_FALLBACK_SCSV), or
2. Being unable to communicate with version-intolerant servers (the situation
without any fallback)?
(I leave out the 3rd option: being vulnerable to MITM downgrades, which I think
we all agree is bad.)

Manuel.

From juhovh@iki.fi  Thu Dec  5 02:53:23 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BECD1ADEBB for ; Thu,  5 Dec 2013 02:53:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 65HAoG-ic-9n for ; Thu,  5 Dec 2013 02:53:21 -0800 (PST)
Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by ietfa.amsl.com (Postfix) with ESMTP id 705911ADF26 for ; Thu,  5 Dec 2013 02:53:21 -0800 (PST)
Received: from [10.171.174.213] (85-76-17-24-nat.elisa-mobile.fi [85.76.17.24]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 46F4B151462; Thu,  5 Dec 2013 12:53:12 +0200 (EET)
Mime-Version: 1.0 (1.0)
From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= 
Content-Type: text/plain; charset=us-ascii
X-Mailer: iPhone Mail (11B554a)
Message-Id: <79C48EEB-9FCE-4AE5-96C0-8AA2193A9354@iki.fi>
Date: Thu, 5 Dec 2013 12:49:33 +0200
Content-Transfer-Encoding: quoted-printable
To: Peter Gutmann 
Cc: "" 
Subject: [TLS] WG actions (was Encrypt-then-MAC again (was padding bug))
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 10:53:23 -0000

> On 5.12.2013, at 5.24, Peter Gutmann  wrote:
>=20
> Eric Rescorla  writes:
>=20
>> This topic was discussed at the TLS WG meeting in Vancouver (since you=20=

>> declined to attend,
>=20
> In any case the WG consists of people on this mailing list, not a select=20=

> few folks in some back-room in Vancouver.

I think the accusation of intentionally organizing meetings so that some mem=
bers cannot attend might be better handled outside this list, since it sound=
s a bit personal.

However, I think the comment above about who is a memer of the WG is valid. I=
 would like to put a bit of emphasis on what RFC 2418 says.

"All working group actions shall be taken in a public forum, and wide partic=
ipation is encouraged. A working group will conduct much of its business via=
 electronic mail distribution lists but may meet periodically to discuss and=
 review task status and progress, to resolve specific issues and to direct f=
uture activities."

Unfortunately I haven't had a chance to take part in any of the face-to-face=
 meetings, so my views are purely from mailing list perspective. The mailing=
 list has extremely good discussion and interesting points, but I get the fe=
eling that many decisions are coming from the "top" (face-to-face meetigs) d=
own here.

When people meet regularly and know each other well, they will share more vi=
ews, this is inevitable. However, IMHO minimizing the gap between the mailin=
g list and meetings, and facilitating communication both ways should be one o=
f the top priorities of WG chairs.=20

Finding ways to get reliable votes instead of vague second hand summaries mi=
ght be a good way to resolve these conflicts. All it would take in its small=
est form would be to open a thread at the list for voting (with no discussio=
n, it should be mostly done at this point), give a certain timebox for the v=
oting and conclude the results on the list. This could be then taken to the f=
ace-to-face meetings.

Does someone know why we don't do this?


Juho


From SRS0=loW3=VM=acm.org=bmoeller@srs.kundenserver.de  Thu Dec  5 03:16:25 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79AA1ADF26 for ; Thu,  5 Dec 2013 03:16:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 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.001, SPF_HELO_PASS=-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 Th460gbblYjc for ; Thu,  5 Dec 2013 03:16:24 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFFC1ADED5 for ; Thu,  5 Dec 2013 03:16:24 -0800 (PST)
Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0Lvx1t-1VWAhS2wwP-017kk6; Thu, 05 Dec 2013 12:16:20 +0100
Received: by mail-oa0-f51.google.com with SMTP id i7so18005583oag.24 for ; Thu, 05 Dec 2013 03:16:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5pkZ93TksxLjtHu0AEVBvgCE2ZztXfDPtzxjguv4kaU=; b=Oh4XG78/umkybRB/wp0JRfPjvu+SB28jEVsjdQ6XCGuPjxIuP8bCl0QjTg4MFpYUfi NJzwqwyJ8Y0KeYUq1n6ZBa2fQfk/EY4kjrgJvAGs03/I/UnvSGsA4FY/rrFpVxVYwYYz gdOWM+kttPFLbfQ94d0HSkLnpHF+GjsEn954PtQCAiZyn9b4YVTLcxmpDIJ6Yv+v8XXa kWpgeAOxJpTkPJ/bkH2X2acTIpoa6+1nTwq6ZyL7UAXYoa760gDiCX2RPKeDB/Q3jiGr ygcx7uqLqbu3U844N/fgPIKnTnSDQyG3KIXSla+wrQsktYjKwmw6qA3jmJPAeLpw+LV+ w/Og==
MIME-Version: 1.0
X-Received: by 10.182.143.103 with SMTP id sd7mr226772obb.70.1386242178475; Thu, 05 Dec 2013 03:16:18 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Thu, 5 Dec 2013 03:16:18 -0800 (PST)
In-Reply-To: 
References:            <529F7E9D.80302@elzevir.fr>   
Date: Thu, 5 Dec 2013 12:16:18 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=e89a8ff1ce9e9ef0e804ecc7a8ad
X-Provags-ID: V02:K0:ARjdo21YP3sj+6CTkUdQbb8qxqbaQJV50Iid3vA5RWU x0HGRbToXPZO5HFHGqRrjWnqrvcFeoZ5ANvqyQwo3BM2MgpIBB gNQXnhSrJW97kScHAVe6TIs9mXOtzgP2L1pCsAt9NdP0rYe+3n sOhUSb/HKDT6/IJDWN0fyIxAK9Ahq7BUxPx79XVLV7j28DAt5s +F3hdFaJjpJ0k0tiQf8me9AU5jTbVtg8JwBIW5V2+RONkO9Tpu FsmFFMbanc0PL5fxAe8h9BtUIJNrcsdcm/f4KWSEwh5Cr+71I6 gMJa1RbFDeCvzd43IKwVTcFKaFwZctfH/IJhgR+t7CNw0CpRzu NuZy4RlOM1tUFoV3+23IRcHycZH/f7hRCHaZQ41ijfrcKXfqEZ hvzVLN0nOsIry+H9aQ3fUaGJHfpjN7jZG4+dmn8EttxmiWRPw2 7EpFK
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 11:17:38 -0000

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

Yngve N. Pettersen :

The SCSV proposal very likely will not "break the web", but my objection is
> that it will require updates to all the servers, and not just the clients,
> and thus take too long to deploy (case in point: 4 years after the Renego
> problem was discovered, 20% of servers are still not patched). Given that.
> 14 years after TLS 1.0 was released, about 1% of servers still only support
> SSL v3. I do not have high hopes of having SCSVs fully deployed in 15 years
> (unless client vendors decide to, or have to, "break the web").
>
> My suggestion have been to update the clients to refuse to use fallback
> when connecting to servers that implement the Renego patch. This have the
> benefit of using a proxy for correct version negotiation, which is already
> deployed on a majority of servers. The drawback of my proposal is that the
> proxy indication is not perfect; there is a small fraction of patched
> servers that are version and/or extension intolerant, and there is a much
> larger fraction of servers that are version intolerant for whatever version
> bytes TLS 1.3+ will use. Some will call the first group as "breaking the
> web", while most will probably agree that the second can definitely be
> called "breaking the web".


> The question is, if client vendors agree to "bull through" and refuse to
> fall back, will the server vendors and web site operators fix their
> implementations, and if so, how quickly? The best option in such a scenario
> would probably be a coordinated same-day release  (alternatively flipping a
> flag) of updated clients, particularly browsers, so that web sites cannot
> use the "switch browser" "advice" for fixing the "browser bug". (Flipping a
> flag might be the better option, since this will allow the updated browsers
> to gain a sufficiently large marketshare before changing the behavior)


As I've mentioned, the two options are not mutually exclusive, so I think
you are constructing a false dichotomy.  We can start to use TLS_FALLBACK_SCSV
ASAP to improve security *ASAP* for connections to *those* servers that do
get updated (80% or even just 10% is better than 0% -- if only the most
important servers that users trust get updated, that's something).  Servers
that aren't version tolerant or extension tolerant will still be just as
broken; having TLS_FALLBACK_SCSV specified doesn't mean that clients are
generally *expected* to fall back, so doesn't affect plans for a fallback
flag flip day or anything like that.

Bodo

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


Yngv=
e N. Pettersen <yngve@spec-work.net>:




The SCSV proposal very likely will not "break the web", but my ob=
jection is that it will require updates to all the servers, and not just th=
e clients, and thus take too long to deploy (case in point: 4 years after t=
he Renego problem was discovered, 20% of servers are still not patched). Gi=
ven that. 14 years after TLS 1.0 was released, about 1% of servers still on=
ly support SSL v3. I do not have high hopes of having SCSVs fully deployed =
in 15 years (unless client vendors decide to, or have to, "break the w=
eb").




My suggestion have been to update the clients to refuse to use fallback whe=
n connecting to servers that implement the Renego patch. This have the bene=
fit of using a proxy for correct version negotiation, which is already depl=
oyed on a majority of servers. The drawback of my proposal is that the prox=
y indication is not perfect; there is a small fraction of patched servers t=
hat are version and/or extension intolerant, and there is a much larger fra=
ction of servers that are version intolerant for whatever version bytes TLS=
 1.3+ will use. Some will call the first group as "breaking the web&qu=
ot;, while most will probably agree that the second can definitely be calle=
d "breaking the web".





The question is, if client vendors agree to "bull through" and re=
fuse to fall back, will the server vendors and web site operators fix their=
 implementations, and if so, how quickly? The best option in such a scenari=
o would probably be a coordinated same-day release =A0(alternatively flippi=
ng a flag) of updated clients, particularly browsers, so that web sites can=
not use the "switch browser" "advice" for fixing the &q=
uot;browser bug". (Flipping a flag might be the better option, since t=
his will allow the updated browsers to gain a sufficiently large marketshar=
e before changing the behavior)



As I've mentioned, the two options are not mutually=
 exclusive, so I think you are constructing a false dichotomy. =A0We can st=
art to use=A0TL=
S_FALLBACK_SCSV ASAP to improve security *ASAP* for connections to *those* =
servers that do get updated (80% or even just 10% is better than 0% -- if o=
nly the most important servers that users trust get updated, that's som=
ething). =A0Servers that aren't version tolerant or extension tolerant will sti=
ll be just as broken; having=A0TLS_FALLBACK_SCSV specified doesn't mean that cl=
ients are generally *expected* to fall back, so doesn't affect plans fo=
r a fallback flag flip day or anything like that.



Bodo



--e89a8ff1ce9e9ef0e804ecc7a8ad--

From SRS0=loW3=VM=acm.org=bmoeller@srs.kundenserver.de  Thu Dec  5 03:45:48 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F0B1ADF68 for ; Thu,  5 Dec 2013 03:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 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.001, SPF_HELO_PASS=-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 MHSmnpyvQUmi for ; Thu,  5 Dec 2013 03:45:47 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id CA9FC1ADF6B for ; Thu,  5 Dec 2013 03:45:46 -0800 (PST)
Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LbTTT-1V9fq919Ip-00l3ms; Thu, 05 Dec 2013 12:45:42 +0100
Received: by mail-oa0-f46.google.com with SMTP id o6so18281667oag.33 for ; Thu, 05 Dec 2013 03:45:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LD6kZxNKcYaiF2eDL7Mc9dxGoiTriEbPS0pzEgS8fOc=; b=HwpH+cpOnsO6SI5P0NfUOBRyXFBV72sLctoLdosZUaLLF3Hg6KfEd+NTjxKyvd0h77 P/aaRfBSibyptBpNpPw+aAzmyZHU3/l1JoZKwqEb+1QDWcbzP+B6PGhFjx7YpHObJB1S jJ6Hxz641eTUBtvb0HbqsNgcEWjuQF3QOz3P7WTbkeA21g/SyVvZ5LfBujmo7tBAJu7s eKr8p6TgLfxubm+R9xBLRRBeGewMsWgg5M4jaKi8pmFbmdZau9b3drIkC9FDHKR8ehDb i/P6zljIyDxFgJIeiHg01UBUgGcBXLxXP9sfNwW5RaEADPa7UL2LXXQarArLvDJFHPaJ 676A==
MIME-Version: 1.0
X-Received: by 10.182.29.33 with SMTP id g1mr903072obh.59.1386243941069; Thu, 05 Dec 2013 03:45:41 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Thu, 5 Dec 2013 03:45:40 -0800 (PST)
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  
Date: Thu, 5 Dec 2013 12:45:40 +0100
Message-ID: 
From: Bodo Moeller 
To: Mohamad Badra 
Content-Type: multipart/alternative; boundary=001a11c2b8b2adfdc204ecc81109
X-Provags-ID: V02:K0:sLMmpAAGSJeNU0OZrWijJrPEnxhVV43CwYDm0iD+HGH DLQ3uahLQjgvBgqmXZXWVFKHz5uENouEPVL5SDbGK3xKZD0lhU aVcywn8p+vN98YjNIJt4jSIVR/UJbn43gUuXJraAqanhSkVvuU GVZOHuPJrxLx/JJ8EgYWQAEHtkher3zNjKndENPBZvve+TaizA HexFRki+gAOnMWSXh5Vuy/Jh3vDpb82ZW2e3qKSCvpN6tpqTns K9OJ4SPooOgbMXEsVI7FTek6K7xOIVbwl3ygusnGte6aXc2R3H 6+OVXOC5gxma3LJQdNQtr34bX1J6nk4bTkijNAxp7k6AGDGJ+/ OlW//xepCNr5ukHCGNp+tVBBR7PvpMrQSzsjpCuL0rCFOWg77V 2q2bD1eMa+9ikwSIHLg9eNz7MYjImOHKMoyTR3Xtq24EmKL81Q mxvtX
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 11:45:48 -0000

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

Mohamad Badra :

For info, I submitted during 2007 and 2008 two documents to enable
> authentication using passwords.
>
> http://tools.ietf.org/id/draft-badra-tls-password-ext-01.txt
> ftp://ftp.kfki.hu/pub/documents/iana/drafts/draft-badra-tls-password-00.txt
>
> Both of them are simple, and secure enough to enable password-based
> authentication
>

That's something different from a password-authenticated key exchange,
though.  In your specs, the client sends the password to the server (in
encrypted form).  If the server isn't actually the legitimate party
expected by the client, this compromises the password.  So the client still
depends heavily on authenticating the server first.

In a *password-authenticated* key exchange, the client doesn't readily
compromise the password if an attacker poses as the server.  So the client
doesn't have to do the usual certificate-based check to authenticate the
server (although, depending on the specific scheme, you could optionally
still do that, to mitigate certain kinds of attacks) -- that's why it's
called "password-authenticated": authentication is inherently based on that
password.  All an attacker posing as the server should get is *one* single
attempt (per client-initiated connection) to guess the password; all the
server will learn, unless that guess happens to be correct, is that that
wasn't the right password.

Bodo

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


Moha=
mad Badra <mbadra@gmail.com>:



For info, I submitted during 2007 and 2008 two documents t=
o enable authentication using passwords.=A0





Both of t=
hem are simple, and secure enough to enable password-based authentication


That's something different from =
a password-authenticated key exchange, though. =A0In your specs, the client=
 sends the password to the server (in encrypted form). =A0If the server isn=
't actually the legitimate party expected by the client, this compromis=
es the password. =A0So the client still depends heavily on authenticating t=
he server first.



In a *password-authenticated* key exchange, the client =
doesn't readily compromise the password if an attacker poses as the ser=
ver. =A0So the client doesn't have to do the usual certificate-based ch=
eck to authenticate the server (although, depending on the specific scheme,=
 you could optionally still do that, to mitigate certain kinds of attacks) =
-- that's why it's called "password-authenticated": authe=
ntication is inherently based on that password. =A0All an attacker posing a=
s the server should get is *one* single attempt (per client-initiated conne=
ction) to guess the password; all the server will learn, unless that guess =
happens to be correct, is that that wasn't the right password.



Bodo



--001a11c2b8b2adfdc204ecc81109--

From SRS0=loW3=VM=acm.org=bmoeller@srs.kundenserver.de  Thu Dec  5 03:48:58 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEBA1ADF7B for ; Thu,  5 Dec 2013 03:48:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 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.001, SPF_HELO_PASS=-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 oTb6LQJh8pgt for ; Thu,  5 Dec 2013 03:48:57 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1EE1ADF77 for ; Thu,  5 Dec 2013 03:48:57 -0800 (PST)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MAkiB-1ViivW0L7b-00BPxh; Thu, 05 Dec 2013 12:48:53 +0100
Received: by mail-ob0-f172.google.com with SMTP id gq1so17606626obb.17 for ; Thu, 05 Dec 2013 03:48:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ETxP0w2yOnZyKRY2B6szLTqeHznORpztjT2iMRVGSn8=; b=ZsmVWm445xluFZ1+oDmuSLOSoQP0oUQ3nkzax+aD4G6vQ8RT2E415Ijz8ZZlmYOUdP nf+mqd9h7sfSa+XJVvPjHij8PR9VDYLBOJXZpcI923MrSxjGZDjHTDDQt5HBATgKybWo x0ujC+UuHCHFoyKCZag5HkbV0ExY1Iq+7BJk/tR4G/M4GUTCFJdbeqeaX8NHgnbrzZSN wcCLELtwqAfQg0fceucw6M7grf4qCpOYWzgJ3IYcDN1GpUMl+d/Fwvu1R02Pc0zO02/y whoxhVvlYhO8k15PqQoFH0XuDjBKrISZ88xfyv7gpUDnRmz6Y2DKXP+JnHo36si0MlSf vR9A==
MIME-Version: 1.0
X-Received: by 10.60.150.238 with SMTP id ul14mr29850321oeb.28.1386244131856;  Thu, 05 Dec 2013 03:48:51 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Thu, 5 Dec 2013 03:48:51 -0800 (PST)
In-Reply-To: <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>
Date: Thu, 5 Dec 2013 12:48:51 +0100
Message-ID: 
From: Bodo Moeller 
To: Dan Harkins , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b5d35b80d29df04ecc81dc5
X-Provags-ID: V02:K0:qbUipVBNLiAQJAIiu+XnRZaHwE1T4c+JKI77ssOiLnG kuUMb1bfEOvJ+KK6NbXvnZMKrvUZBVwW+S/ZL0YGnSdO72jsgB gII++uOaoUVXQE5stVGH0tYAIC9gNcd3ekzqVXZT7GUv4VGzSo xrz2B/4tb4+etPapqMW94S/3MnwtNqiGvlwB1++5EsXUAvRK+l jYRwTAQVo29vwtt6NroGkMZBoJBNOOFBdWncuwUO7okXPO3kfi nHmfGL66oZAqdmbu55eVUFY7B13HcqE6WoXowRNURyv5KR4/7k A+NuFFZHmr73wSh956cs/4IJhsB2b9MCbZw3kDhPnoiI95it9q zmIrvU8J5iHacv+AvQyvnigaU3kNllEFzx8M/Yitxd9e9YUrKG 3+W3JuVuI9TjVnSLb5q2lrSVkr/4P/mxBJUf+XGcVj7YsdYZnP hwAcB
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 11:48:59 -0000

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

Dan Harkins :

The exchange was reviewed by the CFRG with, as Joe noted, satisfactory
> results.


While it is true that Joe noted that, I think the point of the present
discussion is that the protocol wasn't actually reviewed by the CFRG with
satisfactory results.

Bodo

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


Dan =
Harkins <dharkins@lounge.org>:



The =
exchange was reviewed=A0by the CFRG with, as Joe noted, satisfactory result=
s.



While it is true that Joe noted that, I think the point=
 of the present discussion is that the protocol wasn't actually reviewe=
d by the CFRG with satisfactory results.

Bodo




--047d7b5d35b80d29df04ecc81dc5--

From alfredo@pironti.eu  Thu Dec  5 03:52:24 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB7A1ADF89 for ; Thu,  5 Dec 2013 03:52:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.079
X-Spam-Level: 
X-Spam-Status: No, score=-1.079 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, 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 ii30jk45KD22 for ; Thu,  5 Dec 2013 03:52:20 -0800 (PST)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 033681ADF79 for ; Thu,  5 Dec 2013 03:52:19 -0800 (PST)
Received: by mail-ob0-f171.google.com with SMTP id wp18so17545335obc.2 for ; Thu, 05 Dec 2013 03:52:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SD74aPeVFQsOR5Y9uVOel1R8eHl7mFVtg120PMg6SyM=; b=L5xqV6WDE2SFEt6rhUWmNOviVRDBEZPXnRN1hI9UO1L9ZDSe+SknvdxrjLMM7FDPTC d3Ckl7XOEsh53N1cPrAqH0CYQ1m+xQTQ0s3HFshNg+vu8ipGKq7pfkS4LNGdw5VCm9cJ ENaA44Rrv3EMIqZFj2JfcUCJ/cPvacfv91ufU=
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=SD74aPeVFQsOR5Y9uVOel1R8eHl7mFVtg120PMg6SyM=; b=JjF54r85gvhUlrjM2FFx/R/rKO926lFa/QmCmvpNom+TGHGuHE+hK0nukmh/rwd6GP BenMwOgGBucJqKmaKHx/GXGTfP565XyzbQWNGnN/QfRPj6eU68D1Bx5v/x4AfI9Td7PP /zbWzf/RMCknGlaA6JtyTItFbmEt5cRAy8tzfZkwQZf9Wlyo7RbhNBVwZMBlvp65yLpG fC0Sq1FzcXKRBjN9RLn3czy6IVAXU4U8cS7nBzCwsy7xcpURFMzp7V/4Dn/czK0r6lZX 03+Lo6L52b4zaSvnRHVKRF3kAkefD60U9wKqgoKStIPTkAMdK+2UGfSch35Flw3FvOBd bwCw==
X-Gm-Message-State: ALoCoQki9mQn9h1Wt2slLhg148tpz9Gh/ljwWHkip7BIVcvvuk23XS9j4odcki9Rp16ZhSHwSz01
MIME-Version: 1.0
X-Received: by 10.60.44.239 with SMTP id h15mr67870641oem.22.1386244336249; Thu, 05 Dec 2013 03:52:16 -0800 (PST)
Received: by 10.76.180.193 with HTTP; Thu, 5 Dec 2013 03:52:16 -0800 (PST)
X-Originating-IP: [82.224.193.99]
In-Reply-To: <79C48EEB-9FCE-4AE5-96C0-8AA2193A9354@iki.fi>
References: <79C48EEB-9FCE-4AE5-96C0-8AA2193A9354@iki.fi>
Date: Thu, 5 Dec 2013 12:52:16 +0100
Message-ID: 
From: Alfredo Pironti 
To: =?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" , Peter Gutmann 
Subject: Re: [TLS] WG actions (was Encrypt-then-MAC again (was padding bug))
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 11:52:24 -0000

On Thu, Dec 5, 2013 at 11:49 AM, Juho V=C3=A4h=C3=A4-Herttua  wrote:
>
>> On 5.12.2013, at 5.24, Peter Gutmann  wrote:
>>
>> Eric Rescorla  writes:
>>
>>> This topic was discussed at the TLS WG meeting in Vancouver (since you
>>> declined to attend,
>>
>> In any case the WG consists of people on this mailing list, not a select
>> few folks in some back-room in Vancouver.
>
> I think the accusation of intentionally organizing meetings so that some =
members cannot attend might be better handled outside this list, since it s=
ounds a bit personal.
>
> However, I think the comment above about who is a memer of the WG is vali=
d. I would like to put a bit of emphasis on what RFC 2418 says.
>
> "All working group actions shall be taken in a public forum, and wide par=
ticipation is encouraged. A working group will conduct much of its business=
 via electronic mail distribution lists but may meet periodically to discus=
s and review task status and progress, to resolve specific issues and to di=
rect future activities."
>
> Unfortunately I haven't had a chance to take part in any of the face-to-f=
ace meetings, so my views are purely from mailing list perspective. The mai=
ling list has extremely good discussion and interesting points, but I get t=
he feeling that many decisions are coming from the "top" (face-to-face meet=
igs) down here.
>
> When people meet regularly and know each other well, they will share more=
 views, this is inevitable. However, IMHO minimizing the gap between the ma=
iling list and meetings, and facilitating communication both ways should be=
 one of the top priorities of WG chairs.
>
> Finding ways to get reliable votes instead of vague second hand summaries=
 might be a good way to resolve these conflicts. All it would take in its s=
mallest form would be to open a thread at the list for voting (with no disc=
ussion, it should be mostly done at this point), give a certain timebox for=
 the voting and conclude the results on the list. This could be then taken =
to the face-to-face meetings.
>
> Does someone know why we don't do this?

My understanding is that humming is preferred, as it provides some
form of anonymity, while voting would quite break it. Voting/humming
on itself is also a delicate point, as there are not eligible voters
lists; finally, IETF (always according to my understanding) is based
on consensus, so for example, winning by a few votes would still mean
that there is no consensus.

Of course, humming has the drawback of requiring some sort of physical pres=
ence.

Alfredo

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

From SRS0=loW3=VM=acm.org=bmoeller@srs.kundenserver.de  Thu Dec  5 03:59:28 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AD31ADF8B for ; Thu,  5 Dec 2013 03:59:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 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.001, SPF_HELO_PASS=-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 N8Br8RgPKV_u for ; Thu,  5 Dec 2013 03:59:27 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 241E01ADF57 for ; Thu,  5 Dec 2013 03:59:27 -0800 (PST)
Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MfNmw-1WDE8W0G8g-00Oxy4; Thu, 05 Dec 2013 12:59:22 +0100
Received: by mail-oa0-f41.google.com with SMTP id j17so18255294oag.14 for ; Thu, 05 Dec 2013 03:59:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8Ou7H0GG45p6FjAL1IqMbp00px+sk195FXCknHIcNyg=; b=Z1MwTm+P2CHa8IagfuDLptcNSHtRdn+KInicLVaDvGc4inD5gP5VPnaOx2f6I1QO7Y Yzj0pWyStBefW1UJFQGdoQMXeEgeQLDdqoKA7mzGmss8FmlaFX5Orz0bTXt3zJKMfuRQ B/i+xnePhkz1C04YYnXQX0HyD0FZFxCqNiPyFwMB4mNghP6UGjt/QbGDwtHS2tT1OObx QiHdQLc4C+RHADXyUZ/KNA4qSPvn54vZn1tB876ByfIzvlg3SUvbFJdlRIQHlJTsmhPs p/2IyL5QHauPkwL6zUpilaeGLXkq/QHrom7Olc+FeqFTTWEwRPYonHpNtiGEyF8reti8 d9+g==
MIME-Version: 1.0
X-Received: by 10.60.115.164 with SMTP id jp4mr67710037oeb.19.1386244760873; Thu, 05 Dec 2013 03:59:20 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Thu, 5 Dec 2013 03:59:20 -0800 (PST)
In-Reply-To: <79C48EEB-9FCE-4AE5-96C0-8AA2193A9354@iki.fi>
References: <79C48EEB-9FCE-4AE5-96C0-8AA2193A9354@iki.fi>
Date: Thu, 5 Dec 2013 12:59:20 +0100
Message-ID: 
From: Bodo Moeller 
To: "" 
Content-Type: multipart/alternative; boundary=089e01161b468b35b504ecc842e2
X-Provags-ID: V02:K0:h6wsi6Ex/W4JdIteB23zldLr5G2RlejSWZeccLPuMvw nlQKuFOpxUH0LR4TEa6fLMEC73e6YZ8gekPEczoS2BMALBq2sh obfE5T/g5HWuHqEKW0Mh0pbKEKj2Mp4eHt0ojt7U4bM0EZeujv OQfUmcNnKgUNK22SNfFizCTTGimig3WZcq/bBz9aY8MI/9njgP eb7yo8Umf1O5l15B4zvFHKeF33q5xaQOq52WIB49TcggSz/vWr 9G+CmL7zoeTUYhDLoigH/XwK8SSKfTY0KuWBFi/O9/Ax2IT0pT Pb2yAqu390RpAkkeWn4d6yExZEpHniv0x1hrAUpl8rNNjbHCLv kA3SUp8B9C/EKZObpuNP6s/1izlkzzELCqJt0HDaETZkqivC3/ Jkmww+/wDsC86gcREXuYbm/trr4npp3XH6DSW8qSE9zz3fN821 Dth4H
Subject: Re: [TLS] WG actions (was Encrypt-then-MAC again (was padding bug))
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 11:59:28 -0000

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

As I wrote earlier, I think that Eric thought that result from humming
reflected a lack of consensus previous seen on the mailing list, as
previously summarized by him here:
http://www.ietf.org/mail-archive/web/tls/current/msg10004.html

Had there been consensus on the mailing list already, that couldn't have
been silently overruled at the meeting.  Specifically, RFC 2418 requires
that "Decisions reached during a face-to-face meeting about topics or
issues which have not been discussed on the mailing list, or are
significantly different from previously arrived mailing list consensus MUST
be reviewed on the mailing list."  In-person meetings exist to facilitate
discussion, but they're not where decisions are finalized.

Bodo

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


As I wrote earlier, I think that=A0Eric thought that result from humming =
reflected a lack of consensus previous seen on the mailing list, as previou=
sly summarized by him here:=A0http://www.ietf.org/mail-archive/web/tls/=
current/msg10004.html




Had t=
here been consensus on the mailing list already, that couldn't have bee=
n silently overruled at the meeting. =A0Specifically, RFC=A02418 requires t=
hat "Decisions reached during a face-to-face meeting about topics or i=
ssues which have not been discussed on the mailing list, or are significant=
ly different from previously arrived mailing list consensus MUST be reviewe=
d on the mailing list." =A0In-person meetings exist to facilitate disc=
ussion, but they're not where decisions are finalized.



Bodo
<=
div class=3D"gmail_extra">


--089e01161b468b35b504ecc842e2--

From juhovh@iki.fi  Thu Dec  5 04:31:28 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2932F1ADF7B for ; Thu,  5 Dec 2013 04:31:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 aPRS-rfyTsl6 for ; Thu,  5 Dec 2013 04:31:26 -0800 (PST)
Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by ietfa.amsl.com (Postfix) with ESMTP id C47B91ADF65 for ; Thu,  5 Dec 2013 04:31:25 -0800 (PST)
Received: from [10.171.174.213] (85-76-17-24-nat.elisa-mobile.fi [85.76.17.24]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 495391515C5; Thu,  5 Dec 2013 14:31:14 +0200 (EET)
References: <79C48EEB-9FCE-4AE5-96C0-8AA2193A9354@iki.fi> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPhone Mail (11B554a)
From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= 
Date: Thu, 5 Dec 2013 14:27:38 +0200
To: Alfredo Pironti 
Cc: "" , Peter Gutmann 
Subject: Re: [TLS] WG actions (was Encrypt-then-MAC again (was padding bug))
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 12:31:28 -0000

> On 5.12.2013, at 13.52, Alfredo Pironti  wrote:
>=20
> My understanding is that humming is preferred, as it provides some
> form of anonymity, while voting would quite break it. Voting/humming
> on itself is also a delicate point, as there are not eligible voters
> lists; finally, IETF (always according to my understanding) is based
> on consensus, so for example, winning by a few votes would still mean
> that there is no consensus.

This answers my question and I stand corrected, voting is probably not a goo=
d idea at IETF where main goal is the consensus on issues. However, I see pe=
ople already collecting "votes" to prove support for their arguments, becaus=
e a vocal minority can easily send off some people. I believe there are seve=
ral people for whom TLS, although important, is not their main focus.

The main reason seems to be that I rarely see chairs taking part in discussi=
on or steering it to the right direction. The voting suggestion was mainly a=
 wild throw that something should be done. But nevertheless it feels like th=
e decisions are made somewhere else than here...

> Of course, humming has the drawback of requiring some sort of physical pre=
sence.

Someone at the meeting should hum for the whole mailing list probably. But i=
t would be better if him/her was neutral and active participant in the discu=
ssion.


Juho


From mbadra@gmail.com  Thu Dec  5 05:36:31 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056AF1ADEC0 for ; Thu,  5 Dec 2013 05:36:31 -0800 (PST)
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 WD-2vlUqhswh for ; Thu,  5 Dec 2013 05:36:29 -0800 (PST)
Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8DE1ADFB7 for ; Thu,  5 Dec 2013 05:36:29 -0800 (PST)
Received: by mail-ve0-f178.google.com with SMTP id c14so13503706vea.23 for ; Thu, 05 Dec 2013 05:36:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HUO072LFtlQu5piQkDNF9hN/pKIabPvEBA651Gi7Gqo=; b=cLDMvIYl5aIHLhTKpj0QwrKZLWKh6h/VfJ+NrPFqaQEYpHti5iJWEttn9OhS5nKkTM INX+nJArCSOAvtAArdCXpMrb75PF6Oqjen814xzf137s1rOgfT6erOSfPn5sBR6THGB3 pNF+p+VlFpDQ0Ppe5cVgVZYKb2IAhXkTMNQNgsbbN54ACfWu9gNFk+mxDWHLBaJjTild WPTOruwg3Pe19OTxmNI9UUpdIPjaTujyDLR7rk/6E8U6Q7m3yH5VJkZhNDEXu013nDlM MJUN7W0FX2WLMeMN6Hindywm61awkekFsfdaxRuHF0CR5golo8LHLenhfGgykEnX7wBb meGw==
MIME-Version: 1.0
X-Received: by 10.220.147.16 with SMTP id j16mr5733220vcv.28.1386250585669; Thu, 05 Dec 2013 05:36:25 -0800 (PST)
Received: by 10.221.43.138 with HTTP; Thu, 5 Dec 2013 05:36:25 -0800 (PST)
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>   
Date: Thu, 5 Dec 2013 17:36:25 +0400
Message-ID: 
From: Mohamad Badra 
To: Bodo Moeller 
Content-Type: multipart/alternative; boundary=047d7b3436d2bab7d004ecc99de8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 13:36:31 -0000

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

On Thu, Dec 5, 2013 at 3:45 PM, Bodo Moeller  wrote:

>
> That's something different from a password-authenticated key exchange,
> though.  In your specs, the client sends the password to the server (in
> encrypted form).  If the server isn't actually the legitimate party
> expected by the client, this compromises the password.  So the client sti=
ll
> depends heavily on authenticating the server first.
>


Agree. The purpose was to enable client's password-based authentication to
server storing password in clear text or the password's hash ( e.g., LDAP
and EAP).

It cannot be used without a server-side certificate - at least for the
first connection - but if the client share a password with the server, the
public key of the server could be installed on the client host (i.e., as
with SSH), in which case the client will not depend on authenticating the
server during every session.

=E2=80=8BBest regards,
Badra=E2=80=8B

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


On Thu, Dec 5, 2013 a=
t 3:45 PM, Bodo Moeller <bmoeller@acm.or=
g> wrote:









That's something different=
 from a password-authenticated key exchange, though. =C2=A0In your specs, t=
he client sends the password to the server (in encrypted form). =C2=A0If th=
e server isn't actually the legitimate party expected by the client, th=
is compromises the password. =C2=A0So the client still depends heavily on a=
uthenticating the server first.



=C2=A0
Agree. =
The purpose was to enable client's password-based authentication to ser=
ver storing password in clear text or the password's hash ( e.g., LDAP =
and EAP).=C2=A0



It cannot be used=C2=A0without a server-side certificate - at least f=
or the first connection - but if the client share a password with the serve=
r, the public key of the server could be installed on the client host=C2=A0(i.e=
., as with SSH), in which case the client will not depend on authenticating th=
e server during every session.=C2=A0



=E2=80=8BBest regards,

Badra=E2=80=8B



--047d7b3436d2bab7d004ecc99de8--

From mbadra@gmail.com  Thu Dec  5 06:26:38 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD9A1ADFD0 for ; Thu,  5 Dec 2013 06:26:38 -0800 (PST)
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 5vddxxaDF9Y4 for ; Thu,  5 Dec 2013 06:26:37 -0800 (PST)
Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id DDAEB1ADF94 for ; Thu,  5 Dec 2013 06:26:36 -0800 (PST)
Received: by mail-ve0-f169.google.com with SMTP id c14so14102691vea.0 for ; Thu, 05 Dec 2013 06:26:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zYpoVK4ybKcN7vlgdzv4UYtWh/lSwYgE8sZHkNCM1u0=; b=ubydr2D7Ye5sUu/2JLRgmV/Y1JDt5lnI+dTfnJhcwmQeUg/13o4uFd47nw0Y147XcV R/vjy04M2fCl+B2E7Q6U6ktiKTgRpElzdpx5IAl14HooXCMR/dlkQ+0t7SEnHi1efBsc LScyiXSigk7IV6J6cL89lhEn4i08GA6J4QqJOdlgapMqe0+j1i8Rdb7EnTROOLrxt6BS PchaNhE7cjQnqAXXoINQ6njtC9ZzTZc1G5VQKT7DoQ1cO5i3GWXic5L1GgTEgJkRpmwb 6cNBoiRPe7G+kmpE8Grd8MML72P+GTIHvJIqcCO051CXcyTHFAntzmkQEIcR2XUm52HR YUyw==
MIME-Version: 1.0
X-Received: by 10.220.64.200 with SMTP id f8mr840143vci.54.1386253593343; Thu, 05 Dec 2013 06:26:33 -0800 (PST)
Received: by 10.221.43.138 with HTTP; Thu, 5 Dec 2013 06:26:33 -0800 (PST)
In-Reply-To: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>
Date: Thu, 5 Dec 2013 18:26:33 +0400
Message-ID: 
From: Mohamad Badra 
To: "Joseph Salowey (jsalowey)" 
Content-Type: multipart/alternative; boundary=001a11c1eb4400280204ecca51dd
Cc: "" 
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 14:26:39 -0000

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

On Mon, Dec 2, 2013 at 11:23 PM, Joseph Salowey (jsalowey) <
jsalowey@cisco.com> wrote:

> Hi Folks,
>
> Sean, Eric and I have been put together a revised TLS working group
> charter to cover the TLS 1.3 work.   Please review the following charter
> and send any comments to the TLS list by December 16, 2013.
>
> Thanks,
>
> Joe
> [For the Chairs]
>
>
> The TLS (Transport Layer Security) working group was
> established in 1996 to standardize a 'transport layer'
> security protocol.  The basis for the work was SSL
> (Secure Socket Layer) v3.0.  The TLS working group has
> completed a series of specifications that describe the
> TLS protocol v1.0, v1.1, and v1.2 and DTLS
> (Datagram TLS) v1.2 as well as extensions to the
> protocols and ciphersuites.
>
> The primary purpose of the working group is to develop
> (D)TLS v1.3.  Some of the main design goals are as follows,
> in no particular order:
>
> o Develop a mode that encrypts as much of the handshake as
> is possible to reduce the amount of observable data to
> both passive and active attackers.
>
=E2=80=8B=E2=80=8B

Actually, I am surprised that the co-chair Eric=E2=80=8B =E2=80=8Bis=E2=80=
=8B =E2=80=8Breally=E2=80=8B =E2=80=8Bsupporting
the above text!

1-  As =E2=80=8Byou are fun of=E2=80=8B =E2=80=8Bdoing a DHE exchange befor=
e establishing an
ordinary handshake=E2=80=8B to avoid passive/active attacks, why aren't you
supporting its integration to TLS1.3? (I am repeating the same argument
=E2=80=8Bthe WG co-chairs =E2=80=8Bused against adopting
draft-hajjeh-tls-identity-protection as a WG item=E2=80=8B).=E2=80=8B Do yo=
u really need
this major changes to the TLS state machine? ;)

=E2=80=8B2- =E2=80=8BWill your statement [1] apply when encrypting the cert=
ificate during
the "initial" TLS1.3 handshake?

=E2=80=8BBest regards,
Badra=E2=80=8B
=E2=80=8B[1] https://datatracker.ietf.org/ipr/1036/=E2=80=8B

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





On Mon, Dec 2, 2013 at 11:23 PM, Joseph Salowey (jsalowey)=
 <jsalowey@cisco.com> wrote:


Hi Folks,



Sean, Eric and I have been put together a revised TLS working group charter=
 to cover the TLS 1.3 work. =C2=A0 Please review the following charter and =
send any comments to the TLS list by December 16, 2013.



Thanks,



Joe

[For the Chairs]





The TLS (Transport Layer Security) working group was

established in 1996 to standardize a 'transport layer'

security protocol. =C2=A0The basis for the work was SSL

(Secure Socket Layer) v3.0. =C2=A0The TLS working group has

completed a series of specifications that describe the

TLS protocol v1.0, v1.1, and v1.2 and DTLS

(Datagram TLS) v1.2 as well as extensions to the

protocols and ciphersuites.



The primary purpose of the working group is to develop

(D)TLS v1.3. =C2=A0Some of the main design goals are as follows,

in no particular order:



o Develop a mode that encrypts as much of the handshake as

is possible to reduce the amount of observable data to

both passive and active attackers.
=E2=80=8B<=
/span>=E2=80=8B


Actually, I am s=
urprised that the co-chair Eric=E2=80=8B =E2=80=8Bis=E2=80=8B =E2=80=8Breal=
ly=E2=80=8B =E2=80=8Bsupporting the above text!


1- =C2=A0As =E2=80=8Byou are fun of=E2=80=8B =E2=80=8Bdoing a =
DHE exchange before establishing an ordinary handshake=E2=80=8B to avoid pa=
ssive/active attacks, why aren't you supporting its integration to TLS1=
.3? (I am repeating the same argument =E2=80=8Bthe WG co-chairs =E2=80=8Bus=
ed against adopting draft-hajjeh-tls-identity-protection as a WG item=E2=80=
=8B).=E2=80=8B Do you really need this major changes to the TLS=C2=A0state=C2=A0machine? ;)


=E2=80=8B2- =E2=80=8BWill your statement [1] apply when encryp=
ting the certificate during the "initial" TLS1.3 handshake?


=E2=80=8BBest regards,
Badra=E2=80=8B


=E2=80=8B[1]=C2=A0https://datatracker.ietf.org/ipr/1036=
/=E2=80=8B





--001a11c1eb4400280204ecca51dd--

From TurnerS@ieca.com  Thu Dec  5 06:44:56 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3BD1ADFD0 for ; Thu,  5 Dec 2013 06:44:55 -0800 (PST)
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 6m0ebsY861dc for ; Thu,  5 Dec 2013 06:44:54 -0800 (PST)
Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.93.179.5]) by ietfa.amsl.com (Postfix) with ESMTP id 41F171ADEBF for ; Thu,  5 Dec 2013 06:44:54 -0800 (PST)
Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 6FFB1F21A5563; Thu,  5 Dec 2013 08:44:21 -0600 (CST)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 42E20F21A5535 for ; Thu,  5 Dec 2013 08:44:21 -0600 (CST)
Received: from [198.180.150.142] (port=60928 helo=v142.vpn.iad.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VoaAa-0004e4-O8 for tls@ietf.org; Thu, 05 Dec 2013 08:44:49 -0600
From: Sean Turner 
Content-Type: multipart/signed; boundary="Apple-Mail=_02BBBD41-263A-49C3-B6BE-A89C1B051601"; protocol="application/pkcs7-signature"; micalg=sha1
Message-Id: <804C1C30-BD96-42BF-8B24-11262FEE7940@ieca.com>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Date: Thu, 5 Dec 2013 14:44:45 +0000
References: <79C48EEB-9FCE-4AE5-96C0-8AA2193A9354@iki.fi> 
To: tls@ietf.org
In-Reply-To: 
X-Mailer: Apple Mail (2.1822)
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: 198.180.150.142
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (v142.vpn.iad.rg.net) [198.180.150.142]:60928
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Subject: Re: [TLS] WG actions (was Encrypt-then-MAC again (was padding bug))
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 14:44:56 -0000

--Apple-Mail=_02BBBD41-263A-49C3-B6BE-A89C1B051601
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I'm the responsible AD for this group, so let me try to clarify.

Our objective is to have rough consensus on a way forward.  When
there wasn=92t consensus on the mailing list (I agreed with the summary
posted) it is often useful to try to resolve that F2F.  In this case, =
the
WG met and I made it crystal clear that doing nothing is not an option
here.  Hums were taken and there was rough consensus of the people
in the room for the AEAD approach (the minutes reflect this).  But, =
there
are now obviously enough people who disagree on the mailing list and we
don't yet have a draft for the alternative that the F2F meeting =
preferred.
This is why the chairs haven't called consensus, though
I wish they had reported this back more clearly to the mailing list.

I think this has dragged on too long and I'll be meeting with the
chairs to get them to define a process for selecting a way forward.
That should happen this week and they should send something to
the list next week.  I want to see this draft in IETF LC before the
IETF 89 in March.

spt

On Dec 05, 2013, at 11:59, Bodo Moeller  wrote:

> As I wrote earlier, I think that Eric thought that result from humming =
reflected a lack of consensus previous seen on the mailing list, as =
previously summarized by him here: =
http://www.ietf.org/mail-archive/web/tls/current/msg10004.html
>=20
> Had there been consensus on the mailing list already, that couldn't =
have been silently overruled at the meeting.  Specifically, RFC 2418 =
requires that "Decisions reached during a face-to-face meeting about =
topics or issues which have not been discussed on the mailing list, or =
are significantly different from previously arrived mailing list =
consensus MUST be reviewed on the mailing list."  In-person meetings =
exist to facilitate discussion, but they're not where decisions are =
finalized.
>=20
> Bodo
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--Apple-Mail=_02BBBD41-263A-49C3-B6BE-A89C1B051601
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww
ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE
ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT
AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn
tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb
ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg
wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4
rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB
njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD
VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll
Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB
CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE
kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1
N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th
GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i
Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ
v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE
eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi
/aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48
OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM
MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C
CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTEzMTIwNTE0NDQ0NVowIwYJKoZIhvcNAQkEMRYEFBAvI/q1Hz08GcP2CavIQrv1
7tmUMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C
CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF
Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQDkn9Lx5A9prm206wN/F20E0hIo
AaCdC7LC+zPTcqDKwJFkBasHOZEfIQr5QwqUkONMRWb38Q/K2/j73uevmofBaPw+FCI+/bdUYDx5
Bp0MEVumu1SOaKaxaevPe+Nw4bky0QReGmezIyMrgJD6ilHR4343hGb2m4VrZu44nTXiokGC0COj
ppQFOi6QZumMsUoJmVKmtYow9rqkl/fv6FQSah9g6LeUYbBaJKhqI2Wcw8Tl+auycMS/XWlGir7L
qw9haIamLgW1hRGarqYjpryq6EjIhNkidGT7oylLJj/dNKDG1B7kc7cDDowHP1Q3jwe3vCBH8+qt
s+47GpiHrzZFAAAAAAAA

--Apple-Mail=_02BBBD41-263A-49C3-B6BE-A89C1B051601--

From ekr@rtfm.com  Thu Dec  5 06:48:39 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749F61ADF83 for ; Thu,  5 Dec 2013 06:48:39 -0800 (PST)
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 IYZKx_2zCBhc for ; Thu,  5 Dec 2013 06:48:37 -0800 (PST)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9C61AE054 for ; Thu,  5 Dec 2013 06:48:37 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id cc10so9914316wib.16 for ; Thu, 05 Dec 2013 06:48:33 -0800 (PST)
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=MsSRe1Oav+U+izKwLgF87r9HaNRGN6hz3vlgrX5WBSw=; b=GOKgS9g5LvSNnZfSnxxLM6oQoSA/UpzwZV1P3GX2LwdaXzOOtIpYLQEAPWNvT3aeY/ cDnol7TUmbNXu4E2KvuCrUjUg9l6uRQdmWNZCK+xiL3QLzmSoJbuZtEShOleQsE2YkQ4 oY0sCh+w4DMuAvz43Vb3L+bkkUqxzWt5Ubnv+apvfLjNPYzwRAXGk+0CwLTswUHxpQtw aHrV9sxmKkDot4NGBPQQRBwZ6pJYVWmVGvHMFyxpsiqcC2bS4wFCYPgL9DaMW3nLwtg/ VaSTheauzwrOY8vlRHCovhYJYwSoxw36o9NDNYfqNRcvCXkINE45gTofLruHfFFjZ9ZH 8E0g==
X-Gm-Message-State: ALoCoQlmZQVpvA3HULFAqZdbzEV6T2sA9bfPilngnzLwtv+3uFUPruU/qSVXb4g1dj/vQrop0CEF
X-Received: by 10.194.240.197 with SMTP id wc5mr70234703wjc.23.1386254913507;  Thu, 05 Dec 2013 06:48:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 5 Dec 2013 06:47:52 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net> 
From: Eric Rescorla 
Date: Thu, 5 Dec 2013 06:47:52 -0800
Message-ID: 
To: Bodo Moeller 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 14:48:39 -0000

On Thu, Dec 5, 2013 at 3:48 AM, Bodo Moeller  wrote:
> Dan Harkins :
>
>> The exchange was reviewed by the CFRG with, as Joe noted, satisfactory
>> results.
>
>
> While it is true that Joe noted that, I think the point of the present
> discussion is that the protocol wasn't actually reviewed by the CFRG with
> satisfactory results.

Bodo,

The TLS WG isn't chartered to evaluate cryptographic mechanisms, so
where there is some question we generally rely on CFRG for an opinion
as we recently did with Salsa, ChaCha, etc. [1].  (I know you know
this, but to state for the mailing list)


With that in mind, TLS-PWD was the first time we did that and as Joe
stated, we did have a verbal report back from the chair of the CFRG
that they considered it satisfactory. However, based on the present
discussion it's clear that a number of people have concerns about
the security of the underlying mechanism. One of the purposes of
Last Call is to flush out exactly this kind of objection, so that's
good, though I wish we'd caught this earlier. We're still working
on the CFRG interface, so hopefully we'll get better at that part.

Anything we standardize in this area really does need to have a clean
report back from the CFRG. It seems clear that that's not the case
here.

-Ekr
[As chair]

[1] http://www.ietf.org/mail-archive/web/tls/current/msg10221.html

From watsonbladd@gmail.com  Thu Dec  5 08:15:56 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BB81AE0D0 for ; Thu,  5 Dec 2013 08:15:56 -0800 (PST)
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 JaiBKI348LMq for ; Thu,  5 Dec 2013 08:15:55 -0800 (PST)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A7A981AE0C9 for ; Thu,  5 Dec 2013 08:15:54 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id q58so16618752wes.5 for ; Thu, 05 Dec 2013 08:15:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3icOF1xPxomjfEkvlgPXlWuMlT1SbKF1NWlYaBA0ucY=; b=UOBGUqYvp3KnQPnz07K8/aETs4KQZDeu8lByQMMx8Zz9tWypQbDZ+/cQGVDg/Rjpz2 SLdsX+jOy8GXTtTCE3HGWN4u8oJjBD7v//d2rBaTclslXLlk4splYcpKYMSyMOzZO7u4 FgB8pFPI3OoxA+/S7ofmMN7USr1pDzOsTHKc338MXBlJE6Lr4X2S9HJAMyEqV19OAqjX VXYNFdLXyEPOQihiO7bnCx5jI14dZYl/uLKGHzVav4IZWdYSEMTH4cQtjnyYlg13Hk4Z TnBJOkBuKaLSaMlNWB9KK+B+3kHxrCnPihTlnkQjYjYmleyvlV3CRP0gGcmqEWA+JPoe zLng==
MIME-Version: 1.0
X-Received: by 10.180.10.138 with SMTP id i10mr12791334wib.44.1386260150800; Thu, 05 Dec 2013 08:15:50 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Thu, 5 Dec 2013 08:15:50 -0800 (PST)
In-Reply-To: <20131205060621.F23521AB26@ld9781.wdf.sap.corp>
References: <9A043F3CF02CD34C8E74AC1594475C7365423EC2@uxcn10-6.UoA.auckland.ac.nz> <20131205060621.F23521AB26@ld9781.wdf.sap.corp>
Date: Thu, 5 Dec 2013 08:15:50 -0800
Message-ID: 
From: Watson Ladd 
To: mrex@sap.com
Content-Type: text/plain; charset=UTF-8
Cc: "" , Peter Gutmann 
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 16:15:56 -0000

On Wed, Dec 4, 2013 at 10:06 PM, Martin Rex  wrote:

>
> The fragility of GCM worries me personally much more than the
> attack surface of mac-pad-encrypt, e.g.
>
>   Cycling Attacks on GCM, GHASH and Other Polynomial MACs and Hashes
>   Markku-Juhani O. Saarinen
>   http://eprint.iacr.org/2011/202.pdf
What on earth convinced you this paper presented an interesting
result? Why is this forgery more
interesting than all the other forgeries? If you had bothered to do
more research you would see that in the
GCM standardization process this came up, and was appropriately
responded to with "that doesn't change
the security claim, and isn't interesting at all" (paraphrasing).
Mac-pad-encrypt reveals plaintext data. The above doesn't do anything
because if you pick a key uniformly at
random the probability a forgery succeeds is the probability q(x) has
a root at k, which is bounded by things like
being in a field. (Figure it out as an exercise in elementary algebra)
It doesn't matter what form q(x) has.
If you think the above is more worrying than mac-pad-encrypt, you
shouldn't be commenting on cryptography.
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 dharkins@lounge.org  Thu Dec  5 09:15:34 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9201AE122 for ; Thu,  5 Dec 2013 09:15:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 e6C6Iulb8ErZ for ; Thu,  5 Dec 2013 09:15:31 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D46911AE111 for ; Thu,  5 Dec 2013 09:15:31 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6504B1022404C; Thu,  5 Dec 2013 09:15:28 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 5 Dec 2013 09:15:28 -0800 (PST)
Message-ID: <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net> 
Date: Thu, 5 Dec 2013 09:15:28 -0800 (PST)
From: "Dan Harkins" 
To: "Bodo Moeller" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 17:15:34 -0000

On Thu, December 5, 2013 3:48 am, Bodo Moeller wrote:
> Dan Harkins :
>
> The exchange was reviewed by the CFRG with, as Joe noted, satisfactory
>> results.
>
>
> While it is true that Joe noted that, I think the point of the present
> discussion is that the protocol wasn't actually reviewed by the CFRG with
> satisfactory results.

  No, that's not really true.  There is a difference between "your
protocol has
not been proven secure" and "your protocol has a security flaw". And while
the former has been pointed out on this list and the CFRG list, the later
has not.

  You have pointed out an issue with using an in-band server-provided
domain parameter set and I'm going to address that in a subsequent version.
That's not really a flaw in the key exchange, it's how the key exchange has
been inserted into TLS and it can be addressed by some text rewrite. I
am genuinely thankful for your comment and I will address it in a
subsequent version.

  The present discussion on the list boils down to these subjects:

  1) there's no security proof and that is unacceptable (Rene, Watson)
  2) there's nothing special about this protocol so why don't you (being
      me) spend your time working on something else that we (Rene,
      Watson) think is better.
  3) the TLS-pwd benefits and your use cases are not compelling to
      me (Trevor).

The response to #1 is that security proofs have never been required
and we have standards-track protocols today that are susceptible to
offline dictionary attack (every PSK cipher suite). So it's an appeal to a
process that does not exist.

The response to #2 is that lack of implementation of these other
protocols has been hampered by patents and TLS-pwd is not
patented (and the underlying dragonfly key exchange is not patented
either). Theoretically I think there are some elegant alternatives to
TLS-pwd but practically I don't think there are. Regardless though,
there is nothing stopping Rene and/or Watson from doing any work
on any other protocol they think should be advanced. Since I am not
their slave^H^H^H^H^Hgrad student I do not feel compelled to
throw away my work and write papers and wait years as has been
suggested.

(The little uptake in PAKE protocols in the IETF in the recent years is
the result of people following me around from EMU to IPsecme and
now to TLS and after I do the leg work and present a dragonfly-style
exchange someone else comes along and says "hey, me too").

The response to #3 is: so? There is rarely uniformity in viewpoints
as everyone's experience is different. Now there's a choice and if
the benefits of one are not compelling then be happy you can
choose the other.

  To sum, there has been no demonstration of a flaw against the
dragonfly protocol, just some people unhappy that I don't live up
to their standards or that my views of what is important in a PAKE
protocol is not congruent to theirs.

  regards,

  Dan.





From watsonbladd@gmail.com  Thu Dec  5 09:41:24 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302D21ADE84 for ; Thu,  5 Dec 2013 09:41:24 -0800 (PST)
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 RtuH_FFFFCx0 for ; Thu,  5 Dec 2013 09:41:21 -0800 (PST)
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 18AAE1AE03A for ; Thu,  5 Dec 2013 09:41:20 -0800 (PST)
Received: by mail-wi0-f172.google.com with SMTP id en1so23584wid.11 for ; Thu, 05 Dec 2013 09:41:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=amSxRIGJNGRAUjs0x9LQrvAYL2yhz9KGGrtaGkWuZw4=; b=mlkZrLb6jIMXMWqqT4OboZJX7PNYhE8hmvO5LfWqfyeht9LWsADN0jdFjEDIz9V6my X0HSftGVvImIlg5VsJMNBiZvvOWo6vmyOxGN0XbPnPuJitoLCxB8WW2ULdrv+dkVUbw+ 9XnmzqqbHklg9HltcwpBsInEHoF/WCT9pfQFiCTpxHNML3Q9J9CC4W+McXrwFmTrDuUj ekM8UPYiNKK1yhViQzie+NLGWxuxPmTQAthxXr0ZnhbcRPx/4xJdDz7DTwQ3gfdoDjsw pKk5o6Gn3rqo3DKJDkClt8iioubGLtSebz+z7bhs9xhcYhPTMhQyaFuA3rdF3dcgVtux jGBw==
MIME-Version: 1.0
X-Received: by 10.180.13.242 with SMTP id k18mr13126719wic.44.1386265277258; Thu, 05 Dec 2013 09:41:17 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Thu, 5 Dec 2013 09:41:17 -0800 (PST)
In-Reply-To: <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>
Date: Thu, 5 Dec 2013 09:41:17 -0800
Message-ID: 
From: Watson Ladd 
To: Dan Harkins 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 17:41:24 -0000

I disagree with the summary of my position.
TlS-SRP is deployed and implemented now. It can be used freely by
everyone, because the patent is freely licensed.
It has been a part of the TLS standard for years.

There are PAKE protocols with security proofs. It is not unreasonable
to demand that a new PAKE meet the standard which existing
protocols have set. A ZKPK on a hash of the temporary Diffie-Hellman
key+the password is perfectly fine, but quite computation heavy.
But for the examined use case computation work isn't a problem:
embedded devices don't handle thousands of connections.

The history of authentication protocols is littered with protocols
believed secure by their creators which were flawed, only for
the flaws to be discovered years later. Wide-Mouth Frog, early
Kerberos, station-to-station protocol, the various Tor key exchanges,
etc. As a result it is reasonable to demand a proof of any new
protocol in this field, especially when once in the standard it will
take years
to remove if a problem is found.

Dragonfly isn't secure in the sense that there exists an algorithm
that carries out an offline guessing attack. I can't provide the
algorithm:
it depends on a bunch of numbers which are the discrete logarithms of
the various PKEs in the terminology of dragonfly. But it exists,
meaning that stating what it means for dragonfly to be secure is
beyond our current knowledge. (Hash functions suffer from this also,
but in practice this can be worked around) In particular, there are
some random oracles for which dragonfly is broken (namely ones which
jigger the point picking process).

Users depend (unwisely, given the history of this WG) on TLS to be
secure above all else. Arguing that the processes previously existing
in the WG has not provided this guarantee is arguing for increased
scrutiny, not less. Adding complexity to TLS has a cost in making
implementations larger and harder to audit, as well as introducing all
sorts of ways to have misconfiguration. We should only introduce
new options when they satisfy usecases existing ones do not.

What does Dragonfly offer over J-PAKE? What does Dragonfly offer over
SRP? Are these benefits worth losing the benefit of security proofs
and years of analysis? And why isn't J-PAKE suitable for your usecase?
Sincerely,
Watson Ladd

From trevp@trevp.net  Thu Dec  5 10:02:12 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF431AE123 for ; Thu,  5 Dec 2013 10:02:12 -0800 (PST)
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] 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 TFXW3_-RDTpi for ; Thu,  5 Dec 2013 10:02:00 -0800 (PST)
Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8811D1AE132 for ; Thu,  5 Dec 2013 10:02:00 -0800 (PST)
Received: by mail-we0-f179.google.com with SMTP id q59so16695401wes.24 for ; Thu, 05 Dec 2013 10:01:56 -0800 (PST)
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=3GPfeFuFTZXrywHoVjE1A60G7RUc84kbiQqO2Xt9I10=; b=VKIX7UI2wrXr/gHgSmbVKrHeDIAw2mP0hXh1Lqq4akdDGun9SmUIKV4cpuo0tAv2dR /WJ65aauJF86NOoPIIeTEnH9RwElLLfEb35XSVAQm44zb25swRdwc1/qowpTJ0pzmp+t FZO61WYaPd7XXuMleHN1NkKZqjxGtc0HMbCJFKojvG0vpda0zssZjulUE8e0KOYs1f2w Hxl19mZGk4/AKiY8nnhbkU+56RO3yda+q3JmuCz4NPFQ7MPO53SAnsN7lgpjr3/j3fUj G6Vb7NQbt8P55wTLSpiopeyyZ4DtLFt/wlFrXO2lusVB4HzFQQyzn3LJWgNKfs+kQRsV D1aQ==
X-Gm-Message-State: ALoCoQnFqEWD5IkHC1YqdKNvdynK3d8PNhHdLANzpycOQVln/w+3Fx+2+XHblVtbpkJX08FZ8DbU
MIME-Version: 1.0
X-Received: by 10.180.108.162 with SMTP id hl2mr5866wib.56.1386266516654; Thu, 05 Dec 2013 10:01:56 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Thu, 5 Dec 2013 10:01:56 -0800 (PST)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>
Date: Thu, 5 Dec 2013 10:01:56 -0800
Message-ID: 
From: Trevor Perrin 
To: Dan Harkins 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 18:02:12 -0000

On Thu, Dec 5, 2013 at 9:15 AM, Dan Harkins  wrote:
>
> On Thu, December 5, 2013 3:48 am, Bodo Moeller wrote:
>> Dan Harkins :
>>
>> The exchange was reviewed by the CFRG with, as Joe noted, satisfactory
>>> results.
>>
>>
>> While it is true that Joe noted that, I think the point of the present
>> discussion is that the protocol wasn't actually reviewed by the CFRG with
>> satisfactory results.
>
>   No, that's not really true.  There is a difference between "your
> protocol has
> not been proven secure" and "your protocol has a security flaw". And while
> the former has been pointed out on this list and the CFRG list, the later
> has not.

Yes, it has.  Bodo pointed out a security flaw.


>   You have pointed out an issue with using an in-band server-provided
> domain parameter set and I'm going to address that in a subsequent version.
> That's not really a flaw in the key exchange, it's how the key exchange has
> been inserted into TLS and it can be addressed by some text rewrite. I
> am genuinely thankful for your comment and I will address it in a
> subsequent version.
>
>   The present discussion on the list boils down to these subjects:
>
>   1) there's no security proof and that is unacceptable (Rene, Watson)
>   2) there's nothing special about this protocol so why don't you (being
>       me) spend your time working on something else that we (Rene,
>       Watson) think is better.
>   3) the TLS-pwd benefits and your use cases are not compelling to
>       me (Trevor).
>
> The response to #1 is that security proofs have never been required
> and we have standards-track protocols today that are susceptible to
> offline dictionary attack (every PSK cipher suite). So it's an appeal to a
> process that does not exist.

At Watson points out, times have changed and the bar is higher now.

Regarding PSK: It does not attempt to be a PAKE.  Bringing it up here
is irrelevant.


> The response to #2 is that lack of implementation of these other
> protocols has been hampered by patents

See the discussion around SRP that occurred when you first presented
this.  Any patent FUD which *might* have existed, once, has expired:

http://www.ietf.org/mail-archive/web/tls/current/msg08203.html
http://www.ietf.org/mail-archive/web/tls/current/msg08191.html

Additionally, developments such as Elligator and AugPAKE hold promise
for protocols that have both security proofs *and* no IPR encumbrance.


> and TLS-pwd is not
> patented (and the underlying dragonfly key exchange is not patented
> either). Theoretically I think there are some elegant alternatives to
> TLS-pwd but practically I don't think there are. Regardless though,
> there is nothing stopping Rene and/or Watson from doing any work
> on any other protocol they think should be advanced. Since I am not
> their slave^H^H^H^H^Hgrad student I do not feel compelled to
> throw away my work and write papers and wait years as has been
> suggested.
>
> (The little uptake in PAKE protocols in the IETF in the recent years is
> the result of people following me around from EMU to IPsecme and
> now to TLS and after I do the leg work and present a dragonfly-style
> exchange someone else comes along and says "hey, me too").

People like Tom Wu, Nikos, Quinn Slack, myself, and many others did
the "legwork" for a TLS PAKE years ago (TLS-SRP).  It was deployed in
several TLS libraries, some commercial products, and browser patches
were attempted.

We learned something very significant about TLS PAKE:  Almost no-one
wants it.  Providing usernames in the clear is an unacceptable leak of
information, and front-end TLS machines are rarely where sites wish to
perform user authentication.


> The response to #3 is: so? There is rarely uniformity in viewpoints
> as everyone's experience is different. Now there's a choice and if
> the benefits of one are not compelling then be happy you can
> choose the other.

The benefits of *both* are uncompelling.  The low uptake of TLS/SRP
has nothing to do with this draft's cryptographic differences.  It has
to do with architectural issues with the approach, which your draft
does not improve on.


>   To sum, there has been no demonstration of a flaw against the
> dragonfly protocol, just some people unhappy that I don't live up
> to their standards or that my views of what is important in a PAKE
> protocol is not congruent to theirs.

To sum:  TLS already has an ad-hoc PAKE which is serviceable for those
few application which want such a thing.  We don't need another one.


Trevor

From dharkins@lounge.org  Thu Dec  5 10:24:06 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA13C1AD6BF for ; Thu,  5 Dec 2013 10:24:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 gNO8O4fYvx9T for ; Thu,  5 Dec 2013 10:24:06 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id ECAAC1AE0E1 for ; Thu,  5 Dec 2013 10:24:05 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 56CAD1022404A; Thu,  5 Dec 2013 10:24:02 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 5 Dec 2013 10:24:02 -0800 (PST)
Message-ID: 
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net> 
Date: Thu, 5 Dec 2013 10:24:02 -0800 (PST)
From: "Dan Harkins" 
To: "Watson Ladd" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 18:24:07 -0000

On Thu, December 5, 2013 9:41 am, Watson Ladd wrote:
> I disagree with the summary of my position.
> TlS-SRP is deployed and implemented now. It can be used freely by
> everyone, because the patent is freely licensed.
> It has been a part of the TLS standard for years.

  Your conclusion (you disagree with my summary of your position) is
logically disconnected from your premise (I never stated that TLS-SRP
was not deployed or implemented). In other words, you are demonstrating
the red herring fallacy.

> What does Dragonfly offer over J-PAKE? What does Dragonfly offer over
> SRP? Are these benefits worth losing the benefit of security proofs
> and years of analysis? And why isn't J-PAKE suitable for your usecase?

  I think you are mistaken. No one is proposing that we lose the benefits
or security proofs behind deployed and implemented security protocols.
This is not a zero sum game.

  Dan.




From dharkins@lounge.org  Thu Dec  5 10:40:42 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1B51AE10A for ; Thu,  5 Dec 2013 10:40:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 TAWFCGWwWHA1 for ; Thu,  5 Dec 2013 10:40:39 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 972A11AE107 for ; Thu,  5 Dec 2013 10:40:39 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 09A651022404A; Thu,  5 Dec 2013 10:40:36 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 5 Dec 2013 10:40:36 -0800 (PST)
Message-ID: <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net>
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net> 
Date: Thu, 5 Dec 2013 10:40:36 -0800 (PST)
From: "Dan Harkins" 
To: "Trevor Perrin" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 18:40:42 -0000

On Thu, December 5, 2013 10:01 am, Trevor Perrin wrote:
> On Thu, Dec 5, 2013 at 9:15 AM, Dan Harkins  wrote:
>>
>> On Thu, December 5, 2013 3:48 am, Bodo Moeller wrote:
>>> Dan Harkins :
>>>
>>> The exchange was reviewed by the CFRG with, as Joe noted, satisfactory
>>>> results.
>>>
>>>
>>> While it is true that Joe noted that, I think the point of the present
>>> discussion is that the protocol wasn't actually reviewed by the CFRG
>>> with
>>> satisfactory results.
>>
>>   No, that's not really true.  There is a difference between "your
>> protocol has
>> not been proven secure" and "your protocol has a security flaw". And
>> while
>> the former has been pointed out on this list and the CFRG list, the
>> later
>> has not.
>
> Yes, it has.  Bodo pointed out a security flaw.

  You should read the entire email before you respond to it. Like the
very next 6 lines.

>>   You have pointed out an issue with using an in-band server-provided
>> domain parameter set and I'm going to address that in a subsequent
>> version.
>> That's not really a flaw in the key exchange, it's how the key exchange
>> has
>> been inserted into TLS and it can be addressed by some text rewrite. I
>> am genuinely thankful for your comment and I will address it in a
>> subsequent version.
>>
>>   The present discussion on the list boils down to these subjects:
>>
>>   1) there's no security proof and that is unacceptable (Rene, Watson)
>>   2) there's nothing special about this protocol so why don't you (being
>>       me) spend your time working on something else that we (Rene,
>>       Watson) think is better.
>>   3) the TLS-pwd benefits and your use cases are not compelling to
>>       me (Trevor).
>>
>> The response to #1 is that security proofs have never been required
>> and we have standards-track protocols today that are susceptible to
>> offline dictionary attack (every PSK cipher suite). So it's an appeal to
>> a
>> process that does not exist.
>
> At Watson points out, times have changed and the bar is higher now.

  You are appealing to a process that does not exist.

>> The response to #2 is that lack of implementation of these other
>> protocols has been hampered by patents
>
> See the discussion around SRP that occurred when you first presented
> this.  Any patent FUD which *might* have existed, once, has expired:
>
> http://www.ietf.org/mail-archive/web/tls/current/msg08203.html
> http://www.ietf.org/mail-archive/web/tls/current/msg08191.html

  Yes I am aware that the original EKE patent expired. But EKE cannot be
used with elliptic curves. Now I know elliptic curve support is not a
compelling use case for you but, again, so what?

> Additionally, developments such as Elligator and AugPAKE hold promise
> for protocols that have both security proofs *and* no IPR encumbrance.

https://datatracker.ietf.org/ipr/2037/

>> The response to #3 is: so? There is rarely uniformity in viewpoints
>> as everyone's experience is different. Now there's a choice and if
>> the benefits of one are not compelling then be happy you can
>> choose the other.
>
> The benefits of *both* are uncompelling.  The low uptake of TLS/SRP
> has nothing to do with this draft's cryptographic differences.  It has
> to do with architectural issues with the approach, which your draft
> does not improve on.

  You are free to not use this protocol as well if you do not find it
compelling.

  Dan.




From maray@microsoft.com  Thu Dec  5 11:22:16 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875611AE093 for ; Thu,  5 Dec 2013 11:22:16 -0800 (PST)
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 FePnFKNKw9ws for ; Thu,  5 Dec 2013 11:22:13 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id 7955F1AE024 for ; Thu,  5 Dec 2013 11:22:13 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB075.namprd03.prod.outlook.com (10.255.241.155) with Microsoft SMTP Server (TLS) id 15.0.820.5; Thu, 5 Dec 2013 19:22:08 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.159]) with mapi id 15.00.0820.005; Thu, 5 Dec 2013 19:22:08 +0000
From: Marsh Ray 
To: Bodo Moeller , "tls@ietf.org" 
Thread-Topic: [TLS] An SCSV to stop TLS fallback.
Thread-Index: AQHO6jYL3OWisNV4bUWeT9bwHT1KGJo2nY0AgAAA2oCAABDBgIABFMQAgAEyeoCAAExnAIABUZeAgAjIOYCAAHtygIAAmWiAgAADqYCAAAINgIAANHGAgAAjVoCAALN2AIAAhohQ
Date: Thu, 5 Dec 2013 19:22:08 +0000
Message-ID: 
References:            <529F7E9D.80302@elzevir.fr>    
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:ee31::3]
x-forefront-prvs: 00514A2FE6
x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(52034003)(81686001)(59766001)(46102001)(76482001)(74316001)(76786001)(77096001)(81816001)(31966008)(74366001)(47976001)(56776001)(76796001)(54316002)(74876001)(74502001)(4396001)(50986001)(76576001)(47736001)(2656002)(79102001)(51856001)(74662001)(87936001)(69226001)(74706001)(81342001)(15975445006)(33646001)(15202345003)(19580405001)(65816001)(77982001)(49866001)(80976001)(87266001)(53806001)(47446002)(85306002)(63696002)(19580395003)(54356001)(81542001)(80022001)(83322001)(83072001)(56816005)(85852002)(90146001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB075; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::3; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 19:22:16 -0000

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Bodo Moeller
> As I've mentioned, the two options are not mutually exclusive, so I
> think you are constructing a false dichotomy.  We can start to use
> TLS_FALLBACK_SCSV ASAP to improve security *ASAP* for connections to
> *those* servers that do get updated (80% or even just 10% is better
> than 0% -- if only the most important servers that users trust get
> updated, that's something).

It seems to me like there are two scenarios:

Scenario 1.

A vulnerability in *handshake authentication* (stated as before)
is present only in downlevel but mitigated in the highest
protocol version that's common between the legitimate client
and legitimate server.

Thankfully, it's hard to come up with an example for this scenario.
But if it occurs, any protection deployed at the legitimate server
is likely to be rendered useless because the attacker could
impersonate the legitimate server to the legitimate client.
Obviously the attacker would opt not to implement the downgrade
protections in his evil server!

Scenario B.

A vulnerability in *record layer authentication or encryption*
present only in client fallback TLS but mitigated in the highest
protocol version that's common between the legitimate client and
legitimate server.

An example of this scenario is the chosen plaintext attacks on
CBC block padding (e.g., BEAST) that was fixed in 1.1 by sending
an explicit IV. Previous attempts at mitigation had been coded
in OpenSSL years ago for TLS 1.0, but were disabled by default
for compatibility reasons. If an attacker provoked a browser to
fall back to TLS 1.0, he could (in theory) effectively disable
some mitigations in place to prevent this attack.

Protecting against (B) seems like it could be useful, unless it
measurably increases the rate of failed handshakes and delays
in non-attack situations.

http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01#section-3
Server behavior:
> If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the
> highest protocol version supported by the server is higher than
> the version indicated in ClientHello.client_version, the server
> MUST respond with a inappropriate_fallback alert.

Say the server implements TLS 1.0 reasonably well, but believes
it supports 1.2. Unfortuantely, it will successfully negotiate
the use of 1.2 but then crashes and hang the socket open until
the client gives up.

RFC 5246 TLS 1.2 says:

http://tools.ietf.org/html/rfc5246#appendix-E
> TLS clients that wish to negotiate with older servers MAY send any
> value {03,XX} as the record layer version number.  Typical values
> would be {03,00}, the lowest version number supported by the client,
> and the value of ClientHello.client_version.

and

http://tools.ietf.org/html/rfc5246#section-7.4.1.2
> ClientHello.client_version
>    The version of the TLS protocol by which the client wishes to
>    communicate during this session.  This SHOULD be the latest
>    (highest valued) version supported by the client.

That sounds to me like the client MAY retry with record.version=3D{3,0},
but it SHOULD still send ClientHello.client_version=3D{3,3}.

So for clients that follow RFC 5246 recommendation, what is gained by
sending TLS_FALLBACK_SCSV? Why couldn't we instead recommend that
servers reject with *any* connection attempt for which
ClientHello.client_version < "highest version supported by the server" ?

But draft-bmoeller-tls-downgrade-scsv-01 suggests that clients in the proce=
ss
of auto-downgrading behave otherwise:

http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01#section-4
Client behavior:
> If a client sends a *ClientHello.client_version* containing a lower
> value than the latest (highest-valued) version supported by the
> client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value
> in ClientHello.cipher_suites.

I.e., clients are *lying* about the actual highest version of the
protocol they support and they're doing so against the
SHOULD-level recommendation of the TLS RFC's.

The weakness I see is in draft-bmoeller-tls-downgrade-scsv-01
is that servers are not actually in a position to know the highest
protocol version that the client supports.

Thus a server would have to refuse *any* connection for which the
client sends TLS_FALLBACK_SCSV set. Why? Because the server must
consider the unfortunate possibility that some infernal middlebox
is intolerant to TLS 1.3! (or any future version that the client
may support).

The attacker laughs his ass off as browsers and servers are stuck
in a tangled web of little lies mostly built on good intentions.

Sending a flag to say "oh by the way I'm lying about my highest
version" is not a complete fix.

I only see one correct solution: ripping out this auto-downgrade
logic from clients and putting these broken servers and middleboxes
on notice that they have no place on a secure network.

Only then will environment begin to heal and as it does page load
times would become a bit faster.

- Marsh

From trevp@trevp.net  Thu Dec  5 12:42:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7561AE0DD for ; Thu,  5 Dec 2013 12:42:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.208
X-Spam-Level: 
X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77] 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 Y1Oe7qSbsofx for ; Thu,  5 Dec 2013 12:42:33 -0800 (PST)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE9A1AC829 for ; Thu,  5 Dec 2013 12:42:33 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id hq4so280336wib.9 for ; Thu, 05 Dec 2013 12:42:29 -0800 (PST)
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=qBX+c2xrvoPLW1VurYOUD12Gt7xXut0UOwxtnAwB16Q=; b=m6jAltBQ9uHY0olpK6axxmjANN6fi8P3s7COzcJN9OqUbVVDb9pyUBcopjRdOcCGz0 28zsAO4gMdOEH5S73J/UbuHjOQ4fSOtpwHgEH2u4LOptWGgFHSg6RbBVpMfLWGigRop6 YOD9stpaM6iVZMIEkM6DNJtsD1wr9M2vdzaMS9QCTA77NEbgekTGhTKkDl5ygOkeuK6L o7Q8UuW3lmyAgTPD5GOORRPyjeZwGuxdzgpZc442fCaAlET1wn7e7E6yqdqfqtlSsARF YoDcpD8KQNcYeugYyv9RIYXiiOPEkxPWfKo3PsRAjVQjv5u4KGBgKbAP12nif1473PHU /qFQ==
X-Gm-Message-State: ALoCoQmNx5lTtEBlRz2Im4f5q3aJregNT2kCZCLEl7yK103QQu82Ml7z+s+q5gfZhMNY1VFmW5CN
MIME-Version: 1.0
X-Received: by 10.180.187.72 with SMTP id fq8mr13680890wic.26.1386276149513; Thu, 05 Dec 2013 12:42:29 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Thu, 5 Dec 2013 12:42:29 -0800 (PST)
X-Originating-IP: [208.70.28.214]
In-Reply-To: <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>  <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net>
Date: Thu, 5 Dec 2013 12:42:29 -0800
Message-ID: 
From: Trevor Perrin 
To: Dan Harkins 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 20:42:35 -0000

On Thu, Dec 5, 2013 at 10:40 AM, Dan Harkins  wrote:
>
>
> On Thu, December 5, 2013 10:01 am, Trevor Perrin wrote:
>> On Thu, Dec 5, 2013 at 9:15 AM, Dan Harkins  wrote:
>>>
>>> On Thu, December 5, 2013 3:48 am, Bodo Moeller wrote:
>>>> Dan Harkins :
>>>>
>>>> The exchange was reviewed by the CFRG with, as Joe noted, satisfactory
>>>>> results.
>>>>
>>>>
>>>> While it is true that Joe noted that, I think the point of the present
>>>> discussion is that the protocol wasn't actually reviewed by the CFRG
>>>> with
>>>> satisfactory results.
>>>
>>>   No, that's not really true.  There is a difference between "your
>>> protocol has
>>> not been proven secure" and "your protocol has a security flaw". And
>>> while
>>> the former has been pointed out on this list and the CFRG list, the
>>> later
>>> has not.
>>
>> Yes, it has.  Bodo pointed out a security flaw.
>
>   You should read the entire email before you respond to it. Like the
> very next 6 lines.

I did.  Bodo pointed out a security flaw, despite your attempts to spin it.


>>>   The present discussion on the list boils down to these subjects:
>>>
>>>   1) there's no security proof and that is unacceptable (Rene, Watson)
>>>   2) there's nothing special about this protocol so why don't you (being
>>>       me) spend your time working on something else that we (Rene,
>>>       Watson) think is better.
>>>   3) the TLS-pwd benefits and your use cases are not compelling to
>>>       me (Trevor).
>>>
>>> The response to #1 is that security proofs have never been required
>>> and we have standards-track protocols today that are susceptible to
>>> offline dictionary attack (every PSK cipher suite). So it's an appeal to
>>> a
>>> process that does not exist.
>>
>> At Watson points out, times have changed and the bar is higher now.
>
>   You are appealing to a process that does not exist.

The process for acquiring trust in new cryptographic algorithms is
widely understood to involve (A) rigorous security proofs, and (B)
succesfully withstanding years of cryptanalysis (particularly
important if lacking A).

You have neither.


>>> The response to #2 is that lack of implementation of these other
>>> protocols has been hampered by patents
>>
>> See the discussion around SRP that occurred when you first presented
>> this.  Any patent FUD which *might* have existed, once, has expired:
>>
>> http://www.ietf.org/mail-archive/web/tls/current/msg08203.html
>> http://www.ietf.org/mail-archive/web/tls/current/msg08191.html
>
>   Yes I am aware that the original EKE patent expired. But EKE cannot be
> used with elliptic curves.

Not true, for example see Hamburg and Bernstein's Elligator 2 [1],
which could be used as the basis for a DH-EKE style PAKE.


>>> The response to #3 is: so? There is rarely uniformity in viewpoints
>>> as everyone's experience is different. Now there's a choice and if
>>> the benefits of one are not compelling then be happy you can
>>> choose the other.
>>
>> The benefits of *both* are uncompelling.  The low uptake of TLS/SRP
>> has nothing to do with this draft's cryptographic differences.  It has
>> to do with architectural issues with the approach, which your draft
>> does not improve on.
>
>   You are free to not use this protocol as well if you do not find it
> compelling.

We should not standardize protocols which are inferior to existing
ones and to newer alternatives, have insufficient cryptographic
analysis, have no application, and have no support in the WG beside
the draft authors and the NSA [2].

I remain opposed.


Trevor

[1] https://eprint.iacr.org/2013/325.pdf
[2] http://www.ietf.org/mail-archive/web/tls/current/msg08371.html

From SRS0=loW3=VM=acm.org=bmoeller@srs.kundenserver.de  Thu Dec  5 12:56:48 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA47C1ACCDF for ; Thu,  5 Dec 2013 12:56:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 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.001, SPF_HELO_PASS=-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 ZTH54hk553NV for ; Thu,  5 Dec 2013 12:56:48 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id B17A31ADFBB for ; Thu,  5 Dec 2013 12:56:47 -0800 (PST)
Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0LqD3Y-1VJl0d2O12-00eNg8; Thu, 05 Dec 2013 21:56:43 +0100
Received: by mail-oa0-f42.google.com with SMTP id i4so19112663oah.15 for ; Thu, 05 Dec 2013 12:56:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6BjTP7Jfli4NwLFxFsAGnvsBpkupRHjLTCIXkZUdAgw=; b=Sl7vL5rA5zXoT4tRV9jYhXt3SomqI8t+cXwxXnjTfZbD24p4MSqDws0vrDsh0Jq48l RW8YX9LZdjQ6rX5SCnJmuj2vdQrcu1TIVbaQ6x5hGGi0XnUdihFKDeHlfMaJY8gqyfop jKnCl3TF+eG9xoZTao9iD7KlBqQw4TZt2o52yw31opIXk5qNo3ZB1Q+YS7pkVVgVjutx n17A6peTlDQ4XujdXqQudO4/c0CyFGZVc8MmlAI2O0wRJlws2tjhY8Z5sHfjBDEaAFQj r/exIRaifrMGya9HnAO0OpctW5Vx+yBDbDG9oD5fkM+w0BI5mgLcWcYZLJtuP2+uY2gc AZUg==
MIME-Version: 1.0
X-Received: by 10.60.44.193 with SMTP id g1mr16803814oem.47.1386277002307; Thu, 05 Dec 2013 12:56:42 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Thu, 5 Dec 2013 12:56:42 -0800 (PST)
In-Reply-To: <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>
Date: Thu, 5 Dec 2013 21:56:42 +0100
Message-ID: 
From: Bodo Moeller 
To: Dan Harkins 
Content-Type: multipart/alternative; boundary=001a11333dc8486fdc04eccfc4e0
X-Provags-ID: V02:K0:B/nKVdsBR8UA0hJ2V7xYckf4eTcUMGJ9BK+VBFiSoJ4 WYITEvfuq/a/+NcITFGFjJG6fektEQsXmxHTQjv92OcD5Uk3Yf x02hDv2D5EnkOR0mIDizNbwtecSZ0QdGGh6rtaxUDlcD9HhcuY BhH+SfxzOyCjR5CxdY3An+Nuaep8SsNOMqTsWLTKkypyerzaAY LIZK2ltVrHDRKRHlpMlIw5PXtI/5qZufDfaoQRO+v42nVuNVWB n3mrdQppLcbB0Kt8G0Ljg/6WdyMBjwhPTTLKLE5yNubor7qJsH 79yP8hPcOJOisx76F77dPQgx1dtRYpudHGeAA1McZIr28MChgg kyJdHwM4M8UJCE9PYcAG2Igp/bIoEE+CBx42dDiIBpfAIuDkso 1jV3+AldkFtXgsY6Sj41Z0LQ2scBq8+bx2vD2HZDiRvSMqansE g9//X
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 20:56:49 -0000

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

>
> > While it is true that Joe noted that, I think the point of the present
> > discussion is that the protocol wasn't actually reviewed by the CFRG with
> > satisfactory results.
>


>   No, that's not really true.  There is a difference between "your
> protocol has
> not been proven secure" and "your protocol has a security flaw". And while
> the former has been pointed out on this list and the CFRG list, the later
> has not.
>

Right, there's a difference between that (and good reasons to prefer
protocols that *have* been proven secure where those exist), but my main
point here was that there hasn't actually been a thorough protocol review
by the CFRG.

Bodo

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


> While it is true that Joe noted t=
hat, I think the point of the present



> discussion is that the protocol wasn't actually reviewed by the CF=
RG with

> satisfactory results.
=A0


=A0 No, that's not really true. =A0There is a difference be=
tween "your

protocol has

not been proven secure" and "your protocol has a security flaw&qu=
ot;. And while

the former has been pointed out on this list and the CFRG list, the later
has not.

Right, there's a differenc=
e between that (and good reasons to prefer protocols that *have* been prove=
n secure where those exist), but my main point here was that there hasn'=
;t actually been a thorough protocol review by the CFRG.



Bodo




--001a11333dc8486fdc04eccfc4e0--

From rransom.8774@gmail.com  Thu Dec  5 13:10:31 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C310D1AE110 for ; Thu,  5 Dec 2013 13:10:31 -0800 (PST)
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 0-pvkgr0rgqv for ; Thu,  5 Dec 2013 13:10:30 -0800 (PST)
Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6078D1AE106 for ; Thu,  5 Dec 2013 13:10:30 -0800 (PST)
Received: by mail-qc0-f178.google.com with SMTP id i17so5363843qcy.37 for ; Thu, 05 Dec 2013 13:10:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hLO79s3k/4/Jm9LpJxEJNGw/n1DOLSKmB/RlS/I/9/0=; b=doeXWzDdI7iEKVFvIpGdi8MX6WR7llHEqWyjT385jOiwCYCBryFF6/2Nhac1Ul6+5t 7X1ivKnziFi5UxoXWgcfc01S6jMnUSY0Kj4/gZ1PG63lUQSCOBh7CwALLHGVs9Jqr0YS 00TQkdrdUoOiqZ6qYh6d0xvsnwvct0msAsYaNV6buNVDOBvC46pwOMCuzmVGXObFbXEX pAOWfW21v0KgpDPhB9op6gBwHsoO7YgX/xBoN+60kcls2eCWn3rq7DAUJVrh8UlBzwkO xjwmV4xl1DzTmNTUL0D/EN2jBIq4ip33ncaqPQ3t4ByO+6WmB7Gl700FhwSpPv6GHcMK fA/A==
MIME-Version: 1.0
X-Received: by 10.224.80.195 with SMTP id u3mr44005qak.94.1386277826508; Thu, 05 Dec 2013 13:10:26 -0800 (PST)
Received: by 10.229.8.3 with HTTP; Thu, 5 Dec 2013 13:10:26 -0800 (PST)
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>  <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net> 
Date: Thu, 5 Dec 2013 13:10:26 -0800
Message-ID: 
From: Robert Ransom 
To: Trevor Perrin 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 21:10:32 -0000

On 12/5/13, Trevor Perrin  wrote:

> Not true, for example see Hamburg and Bernstein's Elligator 2 [1],
> which could be used as the basis for a DH-EKE style PAKE.

In particular, 2^255-21 factors as a product of two 128-bit numbers
(12405336376215349613*16478153705137396313 and
96110449917563*20607492579733193238707*11*13); it would be fairly easy
to build a Feistel-type block cipher operating between those two
subrings.  (There must be (at least) two natural points in the image
of the Elligator 2 map that could be excised from the set of permitted
public keys; I know there are for Elligator 1.)

(I'm not going to look for ways to split a large subset of 2^414 - 17 now.)


Robert Ransom

From dharkins@lounge.org  Thu Dec  5 13:13:13 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FCA1AE106 for ; Thu,  5 Dec 2013 13:13:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 DZdhwOJCF3mC for ; Thu,  5 Dec 2013 13:13:09 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4551AE0E2 for ; Thu,  5 Dec 2013 13:13:09 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A66E41022404E; Thu,  5 Dec 2013 13:13:05 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 5 Dec 2013 13:13:05 -0800 (PST)
Message-ID: <37a363d2bab1945c4d0bd71b6d9d14ae.squirrel@www.trepanning.net>
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>  <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net> 
Date: Thu, 5 Dec 2013 13:13:05 -0800 (PST)
From: "Dan Harkins" 
To: "Trevor Perrin" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 21:13:14 -0000

On Thu, December 5, 2013 12:42 pm, Trevor Perrin wrote:
> On Thu, Dec 5, 2013 at 10:40 AM, Dan Harkins  wrote:
>>> See the discussion around SRP that occurred when you first presented
>>> this.  Any patent FUD which *might* have existed, once, has expired:
>>>
>>> http://www.ietf.org/mail-archive/web/tls/current/msg08203.html
>>> http://www.ietf.org/mail-archive/web/tls/current/msg08191.html
>>
>>   Yes I am aware that the original EKE patent expired. But EKE cannot be
>> used with elliptic curves.
>
> Not true, for example see Hamburg and Bernstein's Elligator 2 [1],
> which could be used as the basis for a DH-EKE style PAKE.

  Now THAT is an interesting alternative.

  But, alas, the benefit of doing that is uncompelling to you so I don't
know why you mention it. According to you the cryptographic difference
provided by EKE using Elligator public keys has nothing to do with the
architectural differences that you insist are behind the disinterest
(according to you) of PAKE protocols in TLS.

> We should not standardize protocols which are inferior to existing
> ones and to newer alternatives, have insufficient cryptographic
> analysis, have no application, and have no support in the WG beside
> the draft authors and the NSA [2].

  That is just pathetic FUD and a really lame smear. You should be
ashamed of yourself.

> I remain opposed.

  And you even would be opposed to alternatives you suggest instead
(see above). You helped out on TLS-SRP and are opposed to anyone
doing anything else. That is quite obvious.

  Dan.

>
> Trevor
>
> [1] https://eprint.iacr.org/2013/325.pdf
> [2] http://www.ietf.org/mail-archive/web/tls/current/msg08371.html
>


From mbadra@gmail.com  Thu Dec  5 13:30:54 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937F01ACCDE for ; Thu,  5 Dec 2013 13:30:54 -0800 (PST)
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 fAe2hpPe7q9R for ; Thu,  5 Dec 2013 13:30:53 -0800 (PST)
Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1523B1AE17F for ; Thu,  5 Dec 2013 13:30:51 -0800 (PST)
Received: by mail-vc0-f182.google.com with SMTP id lc6so13965656vcb.27 for ; Thu, 05 Dec 2013 13:30:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ichuB8hWqGmqtlT0VqFcbTq3iowQ0KT4pasa12CQYxw=; b=CVS8XJSwvvebBB6uDoFh2ZvBkGUK3MEgmbpBy9EZ7pVkwcDPS3OFCeK9eJi5VepjWB rPovstjV0cNLrtsKnByJfQ6wjjRaZakQxBUBEdOwZ6tdvFPRsn+qTOqkbBtxsKLmq8+A hpX+G7fqhpcCWAQbVMg8nI8QDD2iPC98BV44NKCHR0kOjdnafgWShiw3WNABWUB5mcZs /pJZQZ7QHCWIz+ZL7IouJotDda4tXITloH9ISl5hKjrYFQeQVjtSjdfu1xcWJitZ4luQ cljCCZJWszm6l5q+IrAlSW53TVDBMsisr7GnOxOEhluiHXSKkhQrP125l5RGv2qzjQ5q gQ9g==
MIME-Version: 1.0
X-Received: by 10.220.101.83 with SMTP id b19mr63712vco.42.1386279048451; Thu, 05 Dec 2013 13:30:48 -0800 (PST)
Received: by 10.221.43.138 with HTTP; Thu, 5 Dec 2013 13:30:48 -0800 (PST)
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>  <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net> 
Date: Fri, 6 Dec 2013 01:30:48 +0400
Message-ID: 
From: Mohamad Badra 
To: Trevor Perrin 
Content-Type: multipart/alternative; boundary=047d7b3a7ea43e4f0704ecd03e41
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 21:30:54 -0000

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

On Fri, Dec 6, 2013 at 12:42 AM, Trevor Perrin  wrote:

>
> We should not standardize protocols which are inferior to existing
> ones and to newer alternatives, have insufficient cryptographic
> analysis, have no application,



How was your document betterthan PWD when you initially submitted
draft-taylor-tls-srp-00?=E2=80=8B=E2=80=8B The only security analysis was m=
ade by the
authors of the paper on SRP.


and have no support in the WG beside
> the draft authors and the NSA [2].
>
>
I am not co-author, nor NSA, but I support this document.

Best regards,
Badra

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


On Fri, Dec 6, 2013 a=
t 12:42 AM, Trevor Perrin <trevp@trevp.ne=
t> wrote:




We should not standardize protocols which are inferior to existin=
g

ones and to newer alternatives, have insufficient cryptographic

analysis, have no application, 


<=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
">How was your document betterthan PWD when you initially submitted draft-t=
aylor-tls-srp-00?=E2=80=8B=E2=80=8B The only security analysis was made by =
the authors of the paper on SRP.





and have no support in the WG beside

the draft authors and the NSA [2].



I am not co-author, nor NSA, but I suppo=
rt this document.


Best regards,
Badra


--047d7b3a7ea43e4f0704ecd03e41--

From SRS0=loW3=VM=acm.org=bmoeller@srs.kundenserver.de  Thu Dec  5 13:43:39 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2E31AD8DC for ; Thu,  5 Dec 2013 13:43:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 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.001, SPF_HELO_PASS=-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 o8Hv_1-YDXVC for ; Thu,  5 Dec 2013 13:43:34 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id A60491AC3DA for ; Thu,  5 Dec 2013 13:43:33 -0800 (PST)
Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MgHFG-1WCFjq3xV0-00NKx5; Thu, 05 Dec 2013 22:43:29 +0100
Received: by mail-oa0-f47.google.com with SMTP id k1so19198975oag.34 for ; Thu, 05 Dec 2013 13:43:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vDNGYEzsyEYzzBK6YEqvDHD7fNlyowVmGfPRr+jddgk=; b=m9DCrv/exiQJpe+Y7UXVs8Vo7CZce3gyqYyDejTQJSnuPiMD6NAzzRnBszGQwqLZc6 GFap+xkY9MhiIrNIQ3q+EYzlN+J459EBx9MNopIV0h6sMarCPjSaIVsjlCdBEi6zux43 Bnw0daIFPf1eQ1HDxs1hxqzm72hnOqYuCKwW4qt4MsaNhC+XThIWobgY1d8MtUjGVAw7 KW0sSqsUi9iq4vVOi6Ty6HE13Rc2y0dT/VpfzR3fOpiH+jwlnRbw3V9WPj/PvvG6QwdX NhIw0DiZKzPhpa6Hz/OyeOvoa2N5NUkHKPDPNOCKWQ8jpOhARN9sjCs2eHxEJnSMWsII JzRg==
MIME-Version: 1.0
X-Received: by 10.60.116.230 with SMTP id jz6mr89258oeb.21.1386279807649; Thu, 05 Dec 2013 13:43:27 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Thu, 5 Dec 2013 13:43:27 -0800 (PST)
In-Reply-To: 
References:            <529F7E9D.80302@elzevir.fr>     
Date: Thu, 5 Dec 2013 22:43:27 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0115e84a7e90a104ecd06ba4
X-Provags-ID: V02:K0:i5IMj9zMJcrhSKmfSQL/vAb5k6ew8D53ZDQCr67KAsl j0f6eCEwVv3Zh22EATNgisKZwcApCdUnvAkDtRZ5/m5EOu2rGl eahbN3amC/wuv0pNWDswYUaN8TXbfDmx4T7/Uu+z+iRJVH7JkL SVno2bT7wUKlTLpVCAORdmGjAB0SUTnCp7Clm60PhShqtacNDE UDaPSJCJC4o3UvUnGEzJ33oadaImQSYEcDJlXUrCed8dpHdYzX zlfrlehwg/YgJJ39fPi64aOeT//8T9LSJRp/uFRMCc3x9vj77V KNY7+n0oC52bGM7KKaNjWa0Fd4q+qJZijr3xtDCziYm50nbQdA 4jU1OwHGOsszARMCQTQClYbh7sZrDmCnA0qeL4ZXzfMu8ViCRi IRdFKCtHY7qSd+TLLS8OG+fCADU87M2JbUFqySTyYw5fQ1OtlV 7FpC1
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 21:43:40 -0000

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

Marsh Ray :

> ClientHello.client_version
> >    The version of the TLS protocol by which the client wishes to
> >    communicate during this session.  This SHOULD be the latest
> >    (highest valued) version supported by the client.
>
> That sounds to me like the client MAY retry with record.version={3,0},
> but it SHOULD still send ClientHello.client_version={3,3}.
>
> So for clients that follow RFC 5246 recommendation, what is gained by
> sending TLS_FALLBACK_SCSV?


In this case, TLS_FALLBACK_SCSV is not sent.  TLS_FALLBACK_SCSV is all
about fallback connections in which the client deviates from the above
recommendation, and sends a lower ClientHello.client_version (i.e.,
pretends that it doesn't actually support the latest protocol).  That's
something that clients actually do, because following the RFC
recommendation doesn't allow them to interoperate with all servers in
practice, unfortunately.



> Why couldn't we instead recommend that
> servers reject with *any* connection attempt for which
> ClientHello.client_version < "highest version supported by the server" ?
>

I think you haven't thought that through.  If we did that, it would render
version negotiation pretty much useless: you couldn't ever upgrade servers
to a new protocol version before *all* clients have been upgraded to
support that version.


The weakness I see is in draft-bmoeller-tls-downgrade-scsv-01
> is that servers are not actually in a position to know the highest
> protocol version that the client supports.
>
> Thus a server would have to refuse *any* connection for which the
> client sends TLS_FALLBACK_SCSV set.
>

I don't follow.  Servers would refuse those connections for which the
client (1) sends TLS_FALLBACK_SCSV and (2) doesn't advertise support for
the server's highest supported protocol version.  They don't need to know
the highest protocol version actually supported by the client.


Sending a flag to say "oh by the way I'm lying about my highest
> version" is not a complete fix.
>

It's obviously not a *complete* fix, but it's a fix that addresses relevant
security problems, *and* can actually be deployed (right now, that is,
without having to fix every broken device on the internet first), *and*
does not get in the way of a complete fix.



> I only see one correct solution: ripping out this auto-downgrade
> logic from clients and putting these broken servers and middleboxes
> on notice that they have no place on a secure network.
>
> Only then will environment begin to heal and as it does page load
> times would become a bit faster.


That's the theoretically correct, non-kludgey solution.  However, the
reality is that client implementers have found it necessary in practice to
implement protocol fallback strategies to improve interoperability (and
users tend to prefer bad latency over unresolvable connection failures; I
fear that trying to explain some game theory on browser error pages
wouldn't help).  In case we manage to evict every server from the internet
that doesn't tolerate TLS 1.2 Client Hello message, that need would go away
for now -- but as soon as we start to deploy TLS 1.3, we might then find
out that new servers are around that work fine with TLS 1.2 but don't
tolerate TLS 1.3 Client Hello messages, and we'd be back to square one.
 There are some things we could try to prevent that, but if this Correct
Solution[TM] doesn't work out, it'll be good to have TLS_FALLBACK_SCSV
around as a backup.

Bodo

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


Mars=
h Ray <maray@microsoft.com>:




> ClientHello.client_version

> =A0 =A0The version of the TLS protocol by which the client wishes to
> =A0 =A0communicate during this session. =A0This SHOULD be the latest
> =A0 =A0(highest valued) version supported by the client.



That sounds to me like the client MAY retry with record.version=3D{3,0},
but it SHOULD still send ClientHello.client_version=3D{3,3}.



So for clients that follow RFC 5246 recommendation, what is gained by

sending TLS_FALLBACK_SCSV?

In this case, TL=
S_FALLBACK_SCSV is not sent. =A0TLS_FALLBACK_SCSV is=A0all about fallback c=
onnections in which the client deviates from the above recommendation, and =
sends a lower ClientHello.client_version (i.e., pretends that it doesn'=
t actually support the latest protocol). =A0That's something that clien=
ts actually do, because following the RFC recommendation doesn't allow =
them to interoperate with all servers in practice, unfortunately.



=A0
 Why couldn't we instead =
recommend that


servers reject with *any* connection attempt for which

ClientHello.client_version < "highest version supported by the serv=
er" ?

I think you haven't thou=
ght that through. =A0If we did that, it would render version negotiation pr=
etty much useless: you couldn't ever upgrade servers to a new protocol =
version before *all* clients have been upgraded to support that version.



The weakness I see is in draft-bmoeller-tls=
-downgrade-scsv-01

is that servers=
 are not actually in a position to know the highest
protocol version that the client supports.=



Thus a server would have to refu=
se *any* connection for which the

client sends TL=
S_FALLBACK_SCSV set.

I don't=
 follow. =A0Servers would refuse those connections for which the client (1)=
 sends TLS_FALLBACK_SCSV and (2) doesn't advertise support for the serv=
er's highest supported protocol version. =A0They don't need to know=
 the highest protocol version actually supported by the client.





Sending a flag to say "oh by the way I'm lying about my highest
version" is not a complete fix.

It=
's obviously not a *complete* fix, but it's a fix that addresses re=
levant security problems, *and* can actually be deployed (right now, that i=
s, without having to fix every broken device on the internet first), *and* =
does not get in the way of a complete fix.



=A0

I only see one correct solution: ripping out this auto-downgrade

logic from clients and putting these broken servers and middleboxes

on notice that they have no place on a secure network.



Only then will environment begin to heal and as it does page load

times would become a bit faster.

That's=
 the theoretically correct, non-kludgey solution. =A0However, the reality i=
s that client implementers have found it necessary in practice to implement=
 protocol fallback strategies to improve interoperability (and users tend t=
o prefer bad latency over unresolvable connection failures; I fear that try=
ing to explain some game theory on browser error pages wouldn't help). =
=A0In case we manage to evict every server from the internet that doesn'=
;t tolerate TLS 1.2 Client Hello message, that need would go away for now -=
- but as soon as we start to deploy TLS 1.3, we might then find out that ne=
w servers are around that work fine with TLS 1.2 but don't tolerate TLS=
 1.3 Client Hello messages, and we'd be back to square one. =A0There ar=
e some things we could try to prevent that, but if this Correct Solution[TM=
] doesn't work out, it'll be good to have TLS_FALLBACK_SCSV around =
as a backup.



Bodo



--089e0115e84a7e90a104ecd06ba4--

From trevp@trevp.net  Thu Dec  5 14:14:08 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6861AE21D for ; Thu,  5 Dec 2013 14:14:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.208
X-Spam-Level: 
X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77] 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 BN5Z6pSxWL1J for ; Thu,  5 Dec 2013 14:14:07 -0800 (PST)
Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2207E1AE218 for ; Thu,  5 Dec 2013 14:14:06 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id z12so16985736wgg.3 for ; Thu, 05 Dec 2013 14:14:03 -0800 (PST)
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=NfozyQZFZSsRIF2o7f+LDcuoj9FsT9Ty2jwypLCK6SA=; b=W1hkVHhYjOL2vkshPdoiFVMf+0V7cyDCXXww9HOZ0SGPkbYhT+yORed2vqTQ8YJQHE p4HCg4NPVYplrV3oMf3h6IFzgOTSskBUcbv7zur1sGhgPMxVOqbqIX5fu/GNmHulh6O5 Op0BmXmaggvO8KSnihGEZLhF6B/0TCp5VY3b/BGU5qf7I0UzStm6XFPURb1O61a0jApr 8QMkC6bnRzGzGreVVQQD+mZPPtJ8y5J/u5GSGaRKXv9gPhsfXecX00kMEUNSWnY/fVZW n9geCxhAdRxloZ/J55kKAVjvJ4jFxid9OC3xW3Afrmf4MIs5nRAim9xtMjFUowgIGo8r cpWA==
X-Gm-Message-State: ALoCoQmunaoxif/A+aSZvjjSR/OQOjSaeILQzKlYRX8WDvVrJlqfMUOUDkFR+51fmB1hAJCQADrq
MIME-Version: 1.0
X-Received: by 10.194.104.66 with SMTP id gc2mr1613722wjb.75.1386281643163; Thu, 05 Dec 2013 14:14:03 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Thu, 5 Dec 2013 14:14:03 -0800 (PST)
X-Originating-IP: [208.70.28.214]
In-Reply-To: <37a363d2bab1945c4d0bd71b6d9d14ae.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>  <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net>  <37a363d2bab1945c4d0bd71b6d9d14ae.squirrel@www.trepanning.net>
Date: Thu, 5 Dec 2013 14:14:03 -0800
Message-ID: 
From: Trevor Perrin 
To: Dan Harkins 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 22:14:09 -0000

On Thu, Dec 5, 2013 at 1:13 PM, Dan Harkins  wrote:
>
>
> On Thu, December 5, 2013 12:42 pm, Trevor Perrin wrote:
>> On Thu, Dec 5, 2013 at 10:40 AM, Dan Harkins  wrote:
>>>
>>>   Yes I am aware that the original EKE patent expired. But EKE cannot be
>>> used with elliptic curves.
>>
>> Not true, for example see Hamburg and Bernstein's Elligator 2 [1],
>> which could be used as the basis for a DH-EKE style PAKE.
>
>   Now THAT is an interesting alternative.
>
>   But, alas, the benefit of doing that is uncompelling to you so I don't
> know why you mention it. According to you the cryptographic difference
> provided by EKE using Elligator public keys has nothing to do with the
> architectural differences that you insist are behind the disinterest
> (according to you) of PAKE protocols in TLS.

That's true.  I wouldn't support any PAKE for TLS without some new
interest from TLS implementors.

But if that interest existed, and a PAKE could be integrated into a
TLS handshake in a way that hides the client's username; is simple,
efficient, and secure; and is "state-of-art" relative to alternatives,
that could be worth considering.


>> We should not standardize protocols which are inferior to existing
>> ones and to newer alternatives, have insufficient cryptographic
>> analysis, have no application, and have no support in the WG beside
>> the draft authors and the NSA [2].
>
>   That is just pathetic FUD and a really lame smear. You should be
> ashamed of yourself.

I reviewed the TLS and CFRG mailing lists, and while I found a great
deal of criticism of this draft, the only positive feedback I could
find, prior to Mohamad, was from Kevin Igoe, NSA employee and CFRG
chair [1,2].  I presume Kevin also provided the "verbal report" to our
chairs that CFRG considers this satisfactory.

I find Kevin's enthusiasm strikingly at odds with other expert review
(compare [1,2] vs. this entire thread).  Furthermore, it's well-known
that Kevin's employer expends considerable resources to "Influence
policies, standards, and specification" for commercial cryptography to
make it more "tractable" to cryptanalysis [3].

In these lights, I find Kevin's feedback a source of concern.

Trevor

[1] http://www.ietf.org/mail-archive/web/tls/current/msg08371.html
[2] http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html
[3] http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?_r=1&

From trevp@trevp.net  Thu Dec  5 14:16:38 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8981ADFB8 for ; Thu,  5 Dec 2013 14:16:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.208
X-Spam-Level: 
X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77] 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 TvZ2QTOQ9PLR for ; Thu,  5 Dec 2013 14:16:37 -0800 (PST)
Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id AFB6C1AC3DA for ; Thu,  5 Dec 2013 14:16:36 -0800 (PST)
Received: by mail-we0-f181.google.com with SMTP id x55so17537181wes.12 for ; Thu, 05 Dec 2013 14:16:32 -0800 (PST)
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=axD0+aYruwQGX2Gy9KvB7uhvjIbmugtxvytezKdL2K0=; b=O2KyPFkZVyCw25gFvGpKzUKuVa+oLj1RsYvZr/nAgxyfWyzN6zXbjB4GabjVZ5/in1 Ivn11sEdZ6cG6MLyN0rIfXb2xRly6QDEVFz1tZ6Rv7Bg3YOSeHB6lehH5cEYE+w+w1FF /j5lyq2yEQPaeCnTZ4SE6gTkaGvaxrFAB96vBhmfGgxhyTyG2TfbNY/plNCgonj0/NsK OOikkcAsnWfYEYXWe90zZGxEWFnbqnOBIreiFX89jgKseVRxvFjThJlO1v7vcpI7Wjtr ZhOj25oQD1x+kSNCnygBOPQJg+Ouq96OCBuq5xavgj5Xb3nqDEhCGEfodJIn0RfGbVVR wWQg==
X-Gm-Message-State: ALoCoQkUu6V1T+lOH4W/nt48eGMXiUl8+QUS8pNFoLXO4C6wuxhu55aLutkk1U3JbRGrTf9e1cH6
MIME-Version: 1.0
X-Received: by 10.180.9.74 with SMTP id x10mr73893wia.56.1386281792791; Thu, 05 Dec 2013 14:16:32 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Thu, 5 Dec 2013 14:16:32 -0800 (PST)
X-Originating-IP: [208.70.28.214]
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>  <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net>  
Date: Thu, 5 Dec 2013 14:16:32 -0800
Message-ID: 
From: Trevor Perrin 
To: Mohamad Badra 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 05 Dec 2013 22:16:38 -0000

On Thu, Dec 5, 2013 at 1:30 PM, Mohamad Badra  wrote:
> On Fri, Dec 6, 2013 at 12:42 AM, Trevor Perrin  wrote:
>>
>>
>> We should not standardize protocols which are inferior to existing
>> ones and to newer alternatives, have insufficient cryptographic
>> analysis, have no application,
>
>
>
> How was your document betterthan PWD when you initially submitted
> draft-taylor-tls-srp-00? The only security analysis was made by the authors
> of the paper on SRP.

I didn't submit the initial draft (David Taylor - 2001), nor invent
SRP (Tom Wu - 1998).

Regardless, that was a long time ago, when TLS had no PAKE, the patent
situation was trickier, SRP was state-of-the-art, and people wanted to
experiment with PAKE in the TLS handshake.

If the roles were reversed, and we were proposing TLS-SRP in 2013 when
Dragonfly had been adopted years earlier (and found to be largely
un-useful), we'd be met with the same skepticism.


Trevor

From seonghan.shin@aist.go.jp  Thu Dec  5 17:22:11 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F2F1AE26C for ; Thu,  5 Dec 2013 17:22:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.678
X-Spam-Level: 
X-Spam-Status: No, score=-3.678 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, RCVD_IN_DNSWL_MED=-2.3, 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 9WX_fGzngDDh for ; Thu,  5 Dec 2013 17:22:08 -0800 (PST)
Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with ESMTP id 4D96A1AE267 for ; Thu,  5 Dec 2013 17:22:08 -0800 (PST)
Received: from mail-ie0-f174.google.com ([209.85.223.174]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKUqEmvEX+1gQhidxyBjGe1wrgy2Ch8NvX@postini.com; Thu, 05 Dec 2013 17:22:05 PST
Received: by mail-ie0-f174.google.com with SMTP id at1so70411iec.19 for ; Thu, 05 Dec 2013 17:22:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K+xkC9aEAmWyKtZZgCWX35LwKzxDCt4ijgSuU/R5xPU=; b=LQaRnICpk682J3kDqqH7N46J4omeOrN3EPUDsMiaX+QqD+qBI1j72XIm8vF2zz4D9Q qUJpZctSIQhJxyhPQxg7NpMf8hdBA1V9q2BNZBXSf5sDxjBbmqiHQTaTW3wwVkVuCeHC YpeLZwh2b4Q/M7z4UmfrbVf5Jrh6bA8fx6kto=
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=K+xkC9aEAmWyKtZZgCWX35LwKzxDCt4ijgSuU/R5xPU=; b=hH2EydQxjCpUGH0S4GvVCLC7Ti5yBRW7CZZFnUos3UT8UxWSY55oj98hniIvZzJOVU gvpaYl9nyBcjJPHuJvwgPgDfz/HDeJpNtKx7WMINLpV7k+16YgeC7NkevA4BwB7LeeCj YYqphBgNSVdhWuG+XS4X78QZVu7dVuLP5LwCG2NN4Lr6zdqeYIoy/N9Ja78afYrptRKO cu93HdfMxU2RZVnH/cS2tcAoX2j+wifECwPLN5jd8/GtSBlgq15hYdsAaUCSJs5DWlYN rl8OimQVpqqW4cXexExFfs0RayNvH7695mGHV3KX3ogqJecsLU8GyOZNipfkHH0/SUyF 3w2w==
X-Gm-Message-State: ALoCoQnSv1v5S6iqL6xS9bpu4jj9/ZwimOxCZgPYmRx5K5syowuaPHd9vHXKqmkiaH9DhVKhF9QIkNdXjs+CuiINGD5R8DG9wYtRNWl4FzVnsRkUDT685d7sJGgs/QLxMYbUCTsIuTF2WGyqvfusjShFh3Sa0v6x6Q==
X-Received: by 10.50.16.68 with SMTP id e4mr141823igd.12.1386292924450; Thu, 05 Dec 2013 17:22:04 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.16.68 with SMTP id e4mr141810igd.12.1386292924273; Thu, 05 Dec 2013 17:22:04 -0800 (PST)
Received: by 10.50.119.226 with HTTP; Thu, 5 Dec 2013 17:22:04 -0800 (PST)
In-Reply-To: <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>  <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net>
Date: Fri, 6 Dec 2013 10:22:04 +0900
Message-ID: 
From: SeongHan Shin 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7bdca30a4e6ca504ecd379ed
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 01:22:11 -0000

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

Dear all,

>> Additionally, developments such as Elligator and AugPAKE hold promise
>> for protocols that have both security proofs *and* no IPR encumbrance.
>
>https://datatracker.ietf.org/ipr/2037/

As in the above IPR Disclosures, AugPAKE can be used royal-free for any
conforming implementations.
The patent of AugPAKE was granted in Feb. and April of 2013 from Japan and
U.S. respectively.

Best regards,
Shin


On Fri, Dec 6, 2013 at 3:40 AM, Dan Harkins  wrote:

>
>
> On Thu, December 5, 2013 10:01 am, Trevor Perrin wrote:
> > On Thu, Dec 5, 2013 at 9:15 AM, Dan Harkins  wrote:
> >>
> >> On Thu, December 5, 2013 3:48 am, Bodo Moeller wrote:
> >>> Dan Harkins :
> >>>
> >>> The exchange was reviewed by the CFRG with, as Joe noted, satisfactory
> >>>> results.
> >>>
> >>>
> >>> While it is true that Joe noted that, I think the point of the present
> >>> discussion is that the protocol wasn't actually reviewed by the CFRG
> >>> with
> >>> satisfactory results.
> >>
> >>   No, that's not really true.  There is a difference between "your
> >> protocol has
> >> not been proven secure" and "your protocol has a security flaw". And
> >> while
> >> the former has been pointed out on this list and the CFRG list, the
> >> later
> >> has not.
> >
> > Yes, it has.  Bodo pointed out a security flaw.
>
>   You should read the entire email before you respond to it. Like the
> very next 6 lines.
>
> >>   You have pointed out an issue with using an in-band server-provided
> >> domain parameter set and I'm going to address that in a subsequent
> >> version.
> >> That's not really a flaw in the key exchange, it's how the key exchange
> >> has
> >> been inserted into TLS and it can be addressed by some text rewrite. I
> >> am genuinely thankful for your comment and I will address it in a
> >> subsequent version.
> >>
> >>   The present discussion on the list boils down to these subjects:
> >>
> >>   1) there's no security proof and that is unacceptable (Rene, Watson)
> >>   2) there's nothing special about this protocol so why don't you (being
> >>       me) spend your time working on something else that we (Rene,
> >>       Watson) think is better.
> >>   3) the TLS-pwd benefits and your use cases are not compelling to
> >>       me (Trevor).
> >>
> >> The response to #1 is that security proofs have never been required
> >> and we have standards-track protocols today that are susceptible to
> >> offline dictionary attack (every PSK cipher suite). So it's an appeal to
> >> a
> >> process that does not exist.
> >
> > At Watson points out, times have changed and the bar is higher now.
>
>   You are appealing to a process that does not exist.
>
> >> The response to #2 is that lack of implementation of these other
> >> protocols has been hampered by patents
> >
> > See the discussion around SRP that occurred when you first presented
> > this.  Any patent FUD which *might* have existed, once, has expired:
> >
> > http://www.ietf.org/mail-archive/web/tls/current/msg08203.html
> > http://www.ietf.org/mail-archive/web/tls/current/msg08191.html
>
>   Yes I am aware that the original EKE patent expired. But EKE cannot be
> used with elliptic curves. Now I know elliptic curve support is not a
> compelling use case for you but, again, so what?
>
> > Additionally, developments such as Elligator and AugPAKE hold promise
> > for protocols that have both security proofs *and* no IPR encumbrance.
>
> https://datatracker.ietf.org/ipr/2037/
>
> >> The response to #3 is: so? There is rarely uniformity in viewpoints
> >> as everyone's experience is different. Now there's a choice and if
> >> the benefits of one are not compelling then be happy you can
> >> choose the other.
> >
> > The benefits of *both* are uncompelling.  The low uptake of TLS/SRP
> > has nothing to do with this draft's cryptographic differences.  It has
> > to do with architectural issues with the approach, which your draft
> > does not improve on.
>
>   You are free to not use this protocol as well if you do not find it
> compelling.
>
>   Dan.
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------

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


Dear all,

>> Additionally, developments such =
as Elligator and AugPAKE hold promise

>> for protocols that have both security proofs *and* no IPR encumbra=
nce.

>

>ht=
tps://datatracker.ietf.org/ipr/2037/

As in the =
above IPR Disclosures, AugPAKE can be used royal-fr=
ee for any conforming implementations.


The patent of AugPAKE was granted in Feb. and April of 2013 from Japan and =
U.S. respectively.



Best regards,
Shin


On Fri, Dec 6, 2013 at 3:40 AM, Dan Harkins <dharkins=
@lounge.org> wrote:






On Thu, December 5, 2013 10:01 am, Trevor Perrin wrote:

> On Thu, Dec 5, 2013 at 9:15 AM, Dan Harkins <dharkins@lounge.org> wrote:

>>

>> On Thu, December 5, 2013 3:48 am, Bodo Moeller wrote:

>>> Dan Harkins <dharkin=
s@lounge.org>:

>>>

>>> The exchange was reviewed by the CFRG with, as Joe noted, sati=
sfactory

>>>> results.

>>>

>>>

>>> While it is true that Joe noted that, I think the point of the=
 present

>>> discussion is that the protocol wasn't actually reviewed b=
y the CFRG

>>> with

>>> satisfactory results.

>>

>> =A0 No, that's not really true. =A0There is a difference betwe=
en "your

>> protocol has

>> not been proven secure" and "your protocol has a securit=
y flaw". And

>> while

>> the former has been pointed out on this list and the CFRG list, th=
e

>> later

>> has not.

>

> Yes, it has. =A0Bodo pointed out a security flaw.




=A0 You should read the entire email before you respond to it. Like t=
he

very next 6 lines.




>> =A0 You have pointed out an issue with using an in-band server-pro=
vided

>> domain parameter set and I'm going to address that in a subseq=
uent

>> version.

>> That's not really a flaw in the key exchange, it's how the=
 key exchange

>> has

>> been inserted into TLS and it can be addressed by some text rewrit=
e. I

>> am genuinely thankful for your comment and I will address it in a<=
br>
>> subsequent version.

>>

>> =A0 The present discussion on the list boils down to these subject=
s:

>>

>> =A0 1) there's no security proof and that is unacceptable (Ren=
e, Watson)

>> =A0 2) there's nothing special about this protocol so why don&=
#39;t you (being

>> =A0 =A0 =A0 me) spend your time working on something else that we =
(Rene,

>> =A0 =A0 =A0 Watson) think is better.

>> =A0 3) the TLS-pwd benefits and your use cases are not compelling =
to

>> =A0 =A0 =A0 me (Trevor).

>>

>> The response to #1 is that security proofs have never been require=
d

>> and we have standards-track protocols today that are susceptible t=
o

>> offline dictionary attack (every PSK cipher suite). So it's an=
 appeal to

>> a

>> process that does not exist.

>

> At Watson points out, times have changed and the bar is higher now.



=A0 You are appealing to a process that does not exist.




>> The response to #2 is that lack of implementation of these other
>> protocols has been hampered by patents

>

> See the discussion around SRP that occurred when you first presented
> this. =A0Any patent FUD which *might* have existed, once, has expired:=


>

> http://www.ietf.org/mail-archive/web/tls/current/msg=
08203.html

> http://www.ietf.org/mail-archive/web/tls/current/msg=
08191.html




=A0 Yes I am aware that the original EKE patent expired. But EKE cann=
ot be

used with elliptic curves. Now I know elliptic curve support is not a

compelling use case for you but, again, so what?




> Additionally, developments such as Elligator and AugPAKE hold promise<=
br>
> for protocols that have both security proofs *and* no IPR encumbrance.=





=
https://datatracker.ietf.org/ipr/2037/




>> The response to #3 is: so? There is rarely uniformity in viewpoint=
s

>> as everyone's experience is different. Now there's a choic=
e and if

>> the benefits of one are not compelling then be happy you can

>> choose the other.

>

> The benefits of *both* are uncompelling. =A0The low uptake of TLS/SRP<=
br>
> has nothing to do with this draft's cryptographic differences. =A0=
It has

> to do with architectural issues with the approach, which your draft
> does not improve on.




=A0 You are free to not use this protocol as well if you do not find =
it

compelling.



=A0 Dan.








_______________________________________________

TLS mailing list

TLS@ietf.org

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





-- 
---------------------------------------------=
---------------------

SeongHan Shin
Research Institute for Secure Systems (RISEC)=
,
National Institute of Advanced Industrial Science and Technology (AIST=
),

Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +8=
1-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan=
.shin@aist.go.jp

------------------------------------------------------------------



--047d7bdca30a4e6ca504ecd379ed--

From dharkins@lounge.org  Thu Dec  5 17:50:23 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C771AE1C2 for ; Thu,  5 Dec 2013 17:50:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 damKda2B5chT for ; Thu,  5 Dec 2013 17:50:22 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 224281AE183 for ; Thu,  5 Dec 2013 17:50:22 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 5478D1022404C; Thu,  5 Dec 2013 17:50:18 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 5 Dec 2013 17:50:18 -0800 (PST)
Message-ID: <3895ae1cde1a695cf86767e4977c2218.squirrel@www.trepanning.net>
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>  <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net> 
Date: Thu, 5 Dec 2013 17:50:18 -0800 (PST)
From: "Dan Harkins" 
To: "SeongHan Shin" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 01:50:24 -0000

On Thu, December 5, 2013 5:22 pm, SeongHan Shin wrote:
> Dear all,
>
>>> Additionally, developments such as Elligator and AugPAKE hold promise
>>> for protocols that have both security proofs *and* no IPR encumbrance.
>>
>>https://datatracker.ietf.org/ipr/2037/
>
> As in the above IPR Disclosures, AugPAKE can be used royal-free for any
> conforming implementations.
> The patent of AugPAKE was granted in Feb. and April of 2013 from Japan and
> U.S. respectively.

  No, it doesn't say "any conforming implementation" period. It says:

         "[I]f this document...is adopted as an IETF standards
          track RFC, AIST is prepared to grant a non-exclusive
          royalty-free license for any conforming implementations
          of the adopted version (as an IETF standards track RFC)
          of this document."

So it has to be a standards track RFC. But even that's not really
true because it goes on to say:

         "Needless to say, this does not mean that all the claims
          and the contents in the patent application
          PCT/JP2009/062578 are covered with the non-exclusive
          royalty-free license."

So even if it was a standards track document, AIST reserves
the right to still go after people to whom it granted this
"royalty-free" license. Anyone who took such a license should
get, or get better, legal counsel.

  Dan.



From seonghan.shin@aist.go.jp  Thu Dec  5 18:03:21 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9021AE17F for ; Thu,  5 Dec 2013 18:03:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.678
X-Spam-Level: 
X-Spam-Status: No, score=-3.678 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, RCVD_IN_DNSWL_MED=-2.3, 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 rAAa6TJI_-66 for ; Thu,  5 Dec 2013 18:03:19 -0800 (PST)
Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED481ADFF2 for ; Thu,  5 Dec 2013 18:03:19 -0800 (PST)
Received: from mail-ie0-f181.google.com ([209.85.223.181]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKUqEwY3q+mReUfKhZGRbq0QjDbHQ/3kIn@postini.com; Thu, 05 Dec 2013 18:03:16 PST
Received: by mail-ie0-f181.google.com with SMTP id e14so130944iej.40 for ; Thu, 05 Dec 2013 18:03:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/YRDZQ4rT2Z6n2Y5W00209duQq8duA9XIL8IsBDukkw=; b=N7lcKFRor59cq0snYSurcHGOFRUEzTv+LdzfKG4on7hkS4iJ/s3QXFn7DnW52iZnLH z+wVF3HREGsfz+otyeSK7DYQ0EAQ+ucVgwqCOSvhYReeFGANCqb7PGPXV9czulz0J+Ry AicMt1zw+BS/3gW7KyzZhfbWHoMwxdIYJXQjk=
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:content-type; bh=/YRDZQ4rT2Z6n2Y5W00209duQq8duA9XIL8IsBDukkw=; b=KEI7w8oM/hyN3mTj2FBcUU8p6xT6Hs1DWKs/6d+xUd1yf5ZMNteyzi9Fl/j7qDBCr7 TQajw4MYumR6t3gAdy86J/tiiwLObp2hbKILijAIkVpDHg8RHFXBDBO7QhWj+KyN7lpl QrSaWggNlu8HLF5fi+rUmVSg+yk99Bxgzi5jjLjbdaycFFJknzz72JVHbdRk/J5kXNOy 9bcXSO1NobqwHJZzi75aZSOX7QAWoAlVOjc7gUDpuVFBnwUgFnHZO9/7lNkdZaB/Yuds 9GBBPYNzfE+k5srtSU2azAVZhvzBCeIRMhKrqXhVdSGEjohQQfYLeBaKBfYBmcSScAVT nUzQ==
X-Gm-Message-State: ALoCoQnWgvAEUgSCrfMEqXNBc4r1uaDH07w4j2ERO5C14J8jena/XVbDLkDPRWiPzzoOmgoUhZ0ve5PASBBDeJR5xKd9gdEG02eBx0YHtYFGaOpLz0LG5E3Ho29gRjd7U3IDlst8OzN7HPYijAlh4eWlQg7wVIELRw==
X-Received: by 10.50.43.195 with SMTP id y3mr164551igl.33.1386295395540; Thu, 05 Dec 2013 18:03:15 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.43.195 with SMTP id y3mr164543igl.33.1386295395411; Thu, 05 Dec 2013 18:03:15 -0800 (PST)
Received: by 10.50.119.226 with HTTP; Thu, 5 Dec 2013 18:03:15 -0800 (PST)
In-Reply-To: <3895ae1cde1a695cf86767e4977c2218.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>  <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net>  <3895ae1cde1a695cf86767e4977c2218.squirrel@www.trepanning.net>
Date: Fri, 6 Dec 2013 11:03:15 +0900
Message-ID: 
From: SeongHan Shin 
To: Dan Harkins , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7bfe9fe899214504ecd40c15
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 02:03:22 -0000

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

Dear all,

It is clear from this IPR Disclosures:

         "[I]f this document...is adopted as an IETF standards
          track RFC, AIST is prepared to grant a non-exclusive
          royalty-free license for any conforming implementations
          of the adopted version (as an IETF standards track RFC)
          of this document."

The below means that AugPAKE can be used royalty-free, but other schemes in
the patent can not.

         "Needless to say, this does not mean that all the claims
          and the contents in the patent application
          PCT/JP2009/062578 are covered with the non-exclusive
          royalty-free license."

Best regards,
Shin

On Fri, Dec 6, 2013 at 10:50 AM, Dan Harkins  wrote:

>
>
> On Thu, December 5, 2013 5:22 pm, SeongHan Shin wrote:
> > Dear all,
> >
> >>> Additionally, developments such as Elligator and AugPAKE hold promise
> >>> for protocols that have both security proofs *and* no IPR encumbrance.
> >>
> >>https://datatracker.ietf.org/ipr/2037/<
> https://datatracker.ietf.org/ipr/2037/>
> >
> > As in the above IPR Disclosures, AugPAKE can be used royal-free for any
> > conforming implementations.
> > The patent of AugPAKE was granted in Feb. and April of 2013 from Japan
> and
> > U.S. respectively.
>
>   No, it doesn't say "any conforming implementation" period. It says:
>
>          "[I]f this document...is adopted as an IETF standards
>           track RFC, AIST is prepared to grant a non-exclusive
>           royalty-free license for any conforming implementations
>           of the adopted version (as an IETF standards track RFC)
>           of this document."
>
> So it has to be a standards track RFC. But even that's not really
> true because it goes on to say:
>
>          "Needless to say, this does not mean that all the claims
>           and the contents in the patent application
>           PCT/JP2009/062578 are covered with the non-exclusive
>           royalty-free license."
>
> So even if it was a standards track document, AIST reserves
> the right to still go after people to whom it granted this
> "royalty-free" license. Anyone who took such a license should
> get, or get better, legal counsel.
>
>   Dan.
>
>
>


-- 
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------

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


Dear all,

It is clear from this IPR Disc=
losures:

=A0 =A0 =A0 =A0=A0 "[I]f this document...is adopt=
ed as an IETF standards

=A0 =A0 =A0 =A0 =A0 track RFC, AIST is prepared to grant a non-exclusive
=A0 =A0 =A0 =A0 =A0 royalty-free license for any conforming implementations=


=A0 =A0 =A0 =A0 =A0 of the adopted version (as an IETF standards track RFC)=


=A0 =A0 =A0 =A0 =A0 of this document."

The below means that AugPAKE can b=
e used royalty-free, but other schemes in the patent can not.


=A0 =A0 =A0 =A0=A0 "Needless to say, this does not mean that all t=
he claims

=A0 =A0 =A0 =A0 =A0 and the contents in the patent application

=A0 =A0 =A0 =A0 =A0 PCT/JP2009/062578 are covered with the non-exclusive
=A0 =A0 =A0 =A0 =A0 royalty-free license."

Best regards,
Shin

On Fri, Dec 6, =
2013 at 10:50 AM, Dan Harkins <dharkins@lounge.org> wrote:=







On Thu, December 5, 2013 5:22 pm, SeongHan Shin wrote:

> Dear all,

>

>>> Additionally, developments such as Elligator and AugPAKE hold =
promise

>>> for protocols that have both security proofs *and* no IPR encu=
mbrance.

>>


>>https://datatracker.ietf.org/ipr/2037/<https://datatracker.ietf.or=
g/ipr/2037/>



>

> As in the above IPR Disclosures, AugPAKE can be used royal-free for an=
y

> conforming implementations.

> The patent of AugPAKE was granted in Feb. and April of 2013 from Japan=
 and

> U.S. respectively.




=A0 No, it doesn't say "any conforming implementation" =
period. It says:



=A0 =A0 =A0 =A0 =A0"[I]f this document...is adopted as an IETF standar=
ds

=A0 =A0 =A0 =A0 =A0 track RFC, AIST is prepared to grant a non-exclusive
=A0 =A0 =A0 =A0 =A0 royalty-free license for any conforming implementations=


=A0 =A0 =A0 =A0 =A0 of the adopted version (as an IETF standards track RFC)=


=A0 =A0 =A0 =A0 =A0 of this document."



So it has to be a standards track RFC. But even that's not really

true because it goes on to say:



=A0 =A0 =A0 =A0 =A0"Needless to say, this does not mean that all the c=
laims

=A0 =A0 =A0 =A0 =A0 and the contents in the patent application

=A0 =A0 =A0 =A0 =A0 PCT/JP2009/062578 are covered with the non-exclusive
=A0 =A0 =A0 =A0 =A0 royalty-free license."



So even if it was a standards track document, AIST reserves

the right to still go after people to whom it granted this

"royalty-free" license. Anyone who took such a license should

get, or get better, legal counsel.



=A0 Dan.









-- 
--------------------------------------------=
----------------------

SeongHan Shin
Research Institute for Secure Systems (RISEC)=
,
National Institute of Advanced Industrial Science and Technology (AIST=
),

Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +8=
1-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan=
.shin@aist.go.jp

------------------------------------------------------------------



--047d7bfe9fe899214504ecd40c15--

From dharkins@lounge.org  Thu Dec  5 18:25:04 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1FC1ADFDD for ; Thu,  5 Dec 2013 18:25:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 LJIZowX4MCd0 for ; Thu,  5 Dec 2013 18:25:03 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id ECAC61AE18F for ; Thu,  5 Dec 2013 18:25:02 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 452531022404C; Thu,  5 Dec 2013 18:24:59 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 5 Dec 2013 18:24:59 -0800 (PST)
Message-ID: 
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>  <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net>  <3895ae1cde1a695cf86767e4977c2218.squirrel@www.trepanning.net> 
Date: Thu, 5 Dec 2013 18:24:59 -0800 (PST)
From: "Dan Harkins" 
To: "SeongHan Shin" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 02:25:05 -0000

On Thu, December 5, 2013 6:03 pm, SeongHan Shin wrote:
> Dear all,
>
> It is clear from this IPR Disclosures:
>
>          "[I]f this document...is adopted as an IETF standards
>           track RFC, AIST is prepared to grant a non-exclusive
>           royalty-free license for any conforming implementations
>           of the adopted version (as an IETF standards track RFC)
>           of this document."
>
> The below means that AugPAKE can be used royalty-free, but other schemes
> in the patent can not.
>
>          "Needless to say, this does not mean that all the claims
>           and the contents in the patent application
>           PCT/JP2009/062578 are covered with the non-exclusive
>           royalty-free license."

  No, what is says is that the "royalty-free" license does not necessarily
cover all the claims in the patent and anyone who implements it under
such a "royalty-free" license is still open to being sued by AIST.

  Maybe you should put a "Patent Infringement Considerations" section
in your draft to spell out exactly which claims are not covered by your
"royalty-free" license.

  Dan.

> Best regards,
> Shin
>
> On Fri, Dec 6, 2013 at 10:50 AM, Dan Harkins  wrote:
>
>>
>>
>> On Thu, December 5, 2013 5:22 pm, SeongHan Shin wrote:
>> > Dear all,
>> >
>> >>> Additionally, developments such as Elligator and AugPAKE hold
>> promise
>> >>> for protocols that have both security proofs *and* no IPR
>> encumbrance.
>> >>
>> >>https://datatracker.ietf.org/ipr/2037/<
>> https://datatracker.ietf.org/ipr/2037/>
>> >
>> > As in the above IPR Disclosures, AugPAKE can be used royal-free for
>> any
>> > conforming implementations.
>> > The patent of AugPAKE was granted in Feb. and April of 2013 from Japan
>> and
>> > U.S. respectively.
>>
>>   No, it doesn't say "any conforming implementation" period. It says:
>>
>>          "[I]f this document...is adopted as an IETF standards
>>           track RFC, AIST is prepared to grant a non-exclusive
>>           royalty-free license for any conforming implementations
>>           of the adopted version (as an IETF standards track RFC)
>>           of this document."
>>
>> So it has to be a standards track RFC. But even that's not really
>> true because it goes on to say:
>>
>>          "Needless to say, this does not mean that all the claims
>>           and the contents in the patent application
>>           PCT/JP2009/062578 are covered with the non-exclusive
>>           royalty-free license."
>>
>> So even if it was a standards track document, AIST reserves
>> the right to still go after people to whom it granted this
>> "royalty-free" license. Anyone who took such a license should
>> get, or get better, legal counsel.
>>
>>   Dan.
>>
>>
>>
>
>
> --
> ------------------------------------------------------------------
> SeongHan Shin
> Research Institute for Secure Systems (RISEC),
> National Institute of Advanced Industrial Science and Technology (AIST),
> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
> Tel : +81-29-861-2670/5284
> Fax : +81-29-861-5285
> E-mail : seonghan.shin@aist.go.jp
> ------------------------------------------------------------------
>


From seonghan.shin@aist.go.jp  Thu Dec  5 18:33:42 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D913D1AE209 for ; Thu,  5 Dec 2013 18:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.678
X-Spam-Level: 
X-Spam-Status: No, score=-3.678 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, RCVD_IN_DNSWL_MED=-2.3, 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 IPOOeF4V_ZR7 for ; Thu,  5 Dec 2013 18:33:40 -0800 (PST)
Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6F81AE201 for ; Thu,  5 Dec 2013 18:33:40 -0800 (PST)
Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKUqE3gPgriWhrya/CZkOh04+VULUoPrLo@postini.com; Thu, 05 Dec 2013 18:33:36 PST
Received: by mail-ie0-f172.google.com with SMTP id qd12so183695ieb.17 for ; Thu, 05 Dec 2013 18:33:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uBoKhtj5xr52T7cWtBQ2DHBJ9jS6nvXOen/OSXewXek=; b=nqAWTN+qhdl8tEQ+Qbu24aeX26FKkKClb/vXBmJ5wBupqcv1XjSkkm4x/aUMh11YoR pkmWmqAxZUPQf8k1pRXtMltI5brUjLXqlOHmKR11x7GJqtn/3Dr0QOIaQ9On8JbkOlNL NTgQKEFiH3RuWW2mROzoXlJAgqvKK7OZ1iQbU=
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=uBoKhtj5xr52T7cWtBQ2DHBJ9jS6nvXOen/OSXewXek=; b=KhxJy1X9TRv5mBqwouZMYnkIWKEpvNHPfuGBe0F/nDM6KNZ4cne/QM5QKQoxL6pMsR bDDsyhPFhwWwuyiYNrelmDWFvwbcQ0jmc0bdYSzKaG2RZbotQK41ybKdeBfLhBJixA38 EID9527mcLWMPQFmJzpYkjfbV6qPW3SgUpJWmjT2z7LfnpgsVZzGRzKyYMEyOgZF5m+C aJZLsaB5Qrw6KvvY3tsQoNzOo0k7s8SfVxZh4EPd+qR7Ku1bXer3jHhzeSiiFTsSwg+W pZ6uAClSNoPZB1tsK2CvWOhqLhptbYzErlT/ao1nlOpKxVY9TPr0hwVwV3qIaOpV++ix VBEg==
X-Gm-Message-State: ALoCoQlxwmdurkAksYL8bK5BI7wFenbKMkX2Y0iCxd8l8qiHKvE2P1Uc5FjR06vkGue/Z9F+kxaVZUm6jwhdzaFTN2zNfMVzuvQs+Cwq96GjzN/bvlhGsi5ZxkBrxPIfFITNc7k7bMLKc0BkhdG4Hp2r/cJ66WkKOw==
X-Received: by 10.50.16.68 with SMTP id e4mr345597igd.12.1386297216415; Thu, 05 Dec 2013 18:33:36 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.16.68 with SMTP id e4mr345589igd.12.1386297216283; Thu, 05 Dec 2013 18:33:36 -0800 (PST)
Received: by 10.50.119.226 with HTTP; Thu, 5 Dec 2013 18:33:36 -0800 (PST)
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>  <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net>  <3895ae1cde1a695cf86767e4977c2218.squirrel@www.trepanning.net>  
Date: Fri, 6 Dec 2013 11:33:36 +0900
Message-ID: 
From: SeongHan Shin 
To: Dan Harkins 
Content-Type: multipart/alternative; boundary=047d7bdca30a214a3304ecd47973
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 02:33:43 -0000

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

Dear Dan,

> It is clear from this IPR Disclosures:
>
>          "[I]f this document...is adopted as an IETF standards
>           track RFC, AIST is prepared to grant a non-exclusive
>           royalty-free license for any conforming implementations
>           of the adopted version (as an IETF standards track RFC)
>           of this document."

The statements in the IPR Disclosure was made by an attorney of AIST.
If you think differently, it is better to consult your attorney for its
clarity.

Best regards,
Shin


On Fri, Dec 6, 2013 at 11:24 AM, Dan Harkins  wrote:

>
> On Thu, December 5, 2013 6:03 pm, SeongHan Shin wrote:
> > Dear all,
> >
> > It is clear from this IPR Disclosures:
> >
> >          "[I]f this document...is adopted as an IETF standards
> >           track RFC, AIST is prepared to grant a non-exclusive
> >           royalty-free license for any conforming implementations
> >           of the adopted version (as an IETF standards track RFC)
> >           of this document."
> >
> > The below means that AugPAKE can be used royalty-free, but other schemes
> > in the patent can not.
> >
> >          "Needless to say, this does not mean that all the claims
> >           and the contents in the patent application
> >           PCT/JP2009/062578 are covered with the non-exclusive
> >           royalty-free license."
>
>   No, what is says is that the "royalty-free" license does not necessarily
> cover all the claims in the patent and anyone who implements it under
> such a "royalty-free" license is still open to being sued by AIST.
>
>   Maybe you should put a "Patent Infringement Considerations" section
> in your draft to spell out exactly which claims are not covered by your
> "royalty-free" license.
>
>   Dan.
>
> > Best regards,
> > Shin
> >
> > On Fri, Dec 6, 2013 at 10:50 AM, Dan Harkins 
> wrote:
> >
> >>
> >>
> >> On Thu, December 5, 2013 5:22 pm, SeongHan Shin wrote:
> >> > Dear all,
> >> >
> >> >>> Additionally, developments such as Elligator and AugPAKE hold
> >> promise
> >> >>> for protocols that have both security proofs *and* no IPR
> >> encumbrance.
> >> >>
> >> >>https://datatracker.ietf.org/ipr/2037/<
> >> https://datatracker.ietf.org/ipr/2037/>
> >> >
> >> > As in the above IPR Disclosures, AugPAKE can be used royal-free for
> >> any
> >> > conforming implementations.
> >> > The patent of AugPAKE was granted in Feb. and April of 2013 from Japan
> >> and
> >> > U.S. respectively.
> >>
> >>   No, it doesn't say "any conforming implementation" period. It says:
> >>
> >>          "[I]f this document...is adopted as an IETF standards
> >>           track RFC, AIST is prepared to grant a non-exclusive
> >>           royalty-free license for any conforming implementations
> >>           of the adopted version (as an IETF standards track RFC)
> >>           of this document."
> >>
> >> So it has to be a standards track RFC. But even that's not really
> >> true because it goes on to say:
> >>
> >>          "Needless to say, this does not mean that all the claims
> >>           and the contents in the patent application
> >>           PCT/JP2009/062578 are covered with the non-exclusive
> >>           royalty-free license."
> >>
> >> So even if it was a standards track document, AIST reserves
> >> the right to still go after people to whom it granted this
> >> "royalty-free" license. Anyone who took such a license should
> >> get, or get better, legal counsel.
> >>
> >>   Dan.
> >>
> >>
> >>
> >
> >
> > --
> > ------------------------------------------------------------------
> > SeongHan Shin
> > Research Institute for Secure Systems (RISEC),
> > National Institute of Advanced Industrial Science and Technology (AIST),
> > Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
> > Tel : +81-29-861-2670/5284
> > Fax : +81-29-861-5285
> > E-mail : seonghan.shin@aist.go.jp
> > ------------------------------------------------------------------
> >
>
>


-- 
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------

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


Dear Dan,

> It is clear from this IPR Disclosure=
s:

>

> =A0 =A0 =A0 =A0 =A0"[I]f this document...is adopted as an IETF st=
andards

> =A0 =A0 =A0 =A0 =A0 track RFC, AIST is prepared to grant a non-exclusi=
ve

> =A0 =A0 =A0 =A0 =A0 royalty-free license for any conforming implementa=
tions

> =A0 =A0 =A0 =A0 =A0 of the adopted version (as an IETF standards track=
 RFC)

> =A0 =A0 =A0 =A0 =A0 of this document."

The statements in the IPR Disclosure was made by an attorney of AIS=
T.
If you think differently, it is bett=
er to consult your attorney for its clarity.


Best regards,
Shin


On Fri, Dec 6, 2013 at 11:24 AM, Dan Harkins <dharkins@loun=
ge.org> wrote:




On Thu, December 5, 2013 6:03 pm, SeongHan Shin wrote:


> Dear all,

>

> It is clear from this IPR Disclosures:

>

> =A0 =A0 =A0 =A0 =A0"[I]f this document...is adopted as an IETF st=
andards

> =A0 =A0 =A0 =A0 =A0 track RFC, AIST is prepared to grant a non-exclusi=
ve

> =A0 =A0 =A0 =A0 =A0 royalty-free license for any conforming implementa=
tions

> =A0 =A0 =A0 =A0 =A0 of the adopted version (as an IETF standards track=
 RFC)

> =A0 =A0 =A0 =A0 =A0 of this document."

>

> The below means that AugPAKE can be used royalty-free, but other schem=
es

> in the patent can not.

>

> =A0 =A0 =A0 =A0 =A0"Needless to say, this does not mean that all =
the claims

> =A0 =A0 =A0 =A0 =A0 and the contents in the patent application

> =A0 =A0 =A0 =A0 =A0 PCT/JP2009/062578 are covered with the non-exclusi=
ve

> =A0 =A0 =A0 =A0 =A0 royalty-free license."




=A0 No, what is says is that the "royalty-free" license doe=
s not necessarily

cover all the claims in the patent and anyone who implements it under

such a "royalty-free" license is still open to being sued by AIST=
.



=A0 Maybe you should put a "Patent Infringement Considerations" s=
ection

in your draft to spell out exactly which claims are not covered by your

"royalty-free" license.



=A0 Dan.




> Best regards,

> Shin

>

> On Fri, Dec 6, 2013 at 10:50 AM, Dan Harkins <dharkins@lounge.org> wrote:

>

>>

>>

>> On Thu, December 5, 2013 5:22 pm, SeongHan Shin wrote:

>> > Dear all,

>> >

>> >>> Additionally, developments such as Elligator and AugP=
AKE hold

>> promise

>> >>> for protocols that have both security proofs *and* no=
 IPR

>> encumbrance.

>> >>

>> >>https://datatracker.ietf.org/ipr/2037/<

>> https://datatracker.ietf.org/ipr/2037/>

>> >

>> > As in the above IPR Disclosures, AugPAKE can be used royal-fr=
ee for

>> any

>> > conforming implementations.

>> > The patent of AugPAKE was granted in Feb. and April of 2013 f=
rom Japan

>> and

>> > U.S. respectively.

>>

>> =A0 No, it doesn't say "any conforming implementation&quo=
t; period. It says:

>>

>> =A0 =A0 =A0 =A0 =A0"[I]f this document...is adopted as an IET=
F standards

>> =A0 =A0 =A0 =A0 =A0 track RFC, AIST is prepared to grant a non-exc=
lusive

>> =A0 =A0 =A0 =A0 =A0 royalty-free license for any conforming implem=
entations

>> =A0 =A0 =A0 =A0 =A0 of the adopted version (as an IETF standards t=
rack RFC)

>> =A0 =A0 =A0 =A0 =A0 of this document."

>>

>> So it has to be a standards track RFC. But even that's not rea=
lly

>> true because it goes on to say:

>>

>> =A0 =A0 =A0 =A0 =A0"Needless to say, this does not mean that =
all the claims

>> =A0 =A0 =A0 =A0 =A0 and the contents in the patent application

>> =A0 =A0 =A0 =A0 =A0 PCT/JP2009/062578 are covered with the non-exc=
lusive

>> =A0 =A0 =A0 =A0 =A0 royalty-free license."

>>

>> So even if it was a standards track document, AIST reserves

>> the right to still go after people to whom it granted this

>> "royalty-free" license. Anyone who took such a license s=
hould

>> get, or get better, legal counsel.

>>

>> =A0 Dan.

>>

>>

>>

>

>

> --

> ------------------------------------------------------------------

> SeongHan Shin

> Research Institute for Secure Systems (RISEC),

> National Institute of Advanced Industrial Science and Technology (AIST=
),

> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan

> Tel : +81-29-=
861-2670/5284

> Fax : +81-29-=
861-5285

> E-mail : seonghan.shin@ais=
t.go.jp

> ------------------------------------------------------------------

>







-- 
---------------------------------------------=
---------------------

SeongHan Shin
Research Institute for Secure Systems (RISEC)=
,
National Institute of Advanced Industrial Science and Technology (AIST=
),

Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +8=
1-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan=
.shin@aist.go.jp

------------------------------------------------------------------



--047d7bdca30a214a3304ecd47973--

From watsonbladd@gmail.com  Thu Dec  5 23:24:10 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50EE1AE308 for ; Thu,  5 Dec 2013 23:24:10 -0800 (PST)
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 zrGt5eeA5bzJ for ; Thu,  5 Dec 2013 23:24:08 -0800 (PST)
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 ABBFD1A1F54 for ; Thu,  5 Dec 2013 23:24:07 -0800 (PST)
Received: by mail-wi0-f175.google.com with SMTP id hi5so438655wib.2 for ; Thu, 05 Dec 2013 23:24:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zjB3w+uBby0RcBwNZ00yOCOWiHB5Csaj/+4p1J1I9pw=; b=OEtwYqVtJayPUYI5MShje5/cIiMi1J/NeZEJyJO1FFNNoOU9Xm0R271hJC0XAIapAY 5PUG4ZECNDwXHnhGXGE2xmaL9uefJ04dMwYd8BaNFWr/RmFs3X5+3/nY3m3NZ8UQaO0X axR0vpiklSbefpTCKrQNQ+IZh+HX8EhgFWqbbGEaOXXa2B3enkpCAQ+DPByNHdQP+khZ IyuQ5uKt3hvGs11+OmiAJb9LXzW2w+3D66iapBOIxVgbou3ioDuSbT5s7WB/eti5OgNg VMHIwLt8+mpsKcTRnUiWDup/49WGoG6ReAJI0WDWGn8EUPsSx6hlIzgkmnt+zvphb3v+ VL/Q==
MIME-Version: 1.0
X-Received: by 10.194.85.75 with SMTP id f11mr1643913wjz.14.1386314643443; Thu, 05 Dec 2013 23:24:03 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Thu, 5 Dec 2013 23:24:03 -0800 (PST)
In-Reply-To: <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>  <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net>
Date: Thu, 5 Dec 2013 23:24:03 -0800
Message-ID: 
From: Watson Ladd 
To: Dan Harkins 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 07:24:11 -0000

On Thu, Dec 5, 2013 at 10:40 AM, Dan Harkins  wrote:
>
>
> On Thu, December 5, 2013 10:01 am, Trevor Perrin wrote:
>> On Thu, Dec 5, 2013 at 9:15 AM, Dan Harkins  wrote:
>>>
>>> On Thu, December 5, 2013 3:48 am, Bodo Moeller wrote:
>>>> Dan Harkins :
>>>>
>>>> The exchange was reviewed by the CFRG with, as Joe noted, satisfactory
>>>>> results.
>>>>
>>>>
>>>> While it is true that Joe noted that, I think the point of the present
>>>> discussion is that the protocol wasn't actually reviewed by the CFRG
>>>> with
>>>> satisfactory results.
>>>
>>>   No, that's not really true.  There is a difference between "your
>>> protocol has
>>> not been proven secure" and "your protocol has a security flaw". And
>>> while
>>> the former has been pointed out on this list and the CFRG list, the
>>> later
>>> has not.
>>
>> Yes, it has.  Bodo pointed out a security flaw.
>
>   You should read the entire email before you respond to it. Like the
> very next 6 lines.
>
>>>   You have pointed out an issue with using an in-band server-provided
>>> domain parameter set and I'm going to address that in a subsequent
>>> version.
>>> That's not really a flaw in the key exchange, it's how the key exchange
>>> has
>>> been inserted into TLS and it can be addressed by some text rewrite. I
>>> am genuinely thankful for your comment and I will address it in a
>>> subsequent version.
>>>
>>>   The present discussion on the list boils down to these subjects:
>>>
>>>   1) there's no security proof and that is unacceptable (Rene, Watson)
>>>   2) there's nothing special about this protocol so why don't you (being
>>>       me) spend your time working on something else that we (Rene,
>>>       Watson) think is better.
>>>   3) the TLS-pwd benefits and your use cases are not compelling to
>>>       me (Trevor).
>>>
>>> The response to #1 is that security proofs have never been required
>>> and we have standards-track protocols today that are susceptible to
>>> offline dictionary attack (every PSK cipher suite). So it's an appeal to
>>> a
>>> process that does not exist.
>>
>> At Watson points out, times have changed and the bar is higher now.
>
>   You are appealing to a process that does not exist.
There is no set process for getting things through a WG. Checking
boxes will never make
up for a lack of substance. This argument seems to be that because we
made mistakes in
the past, we can't avoid making them in the future. The process you
seem to think applies
did not prevent RC4, implicit IVs, MAC-pad-encrypt, downgrade attacks,
or the parser complexity
responsible for many security vulnerabilities.

I don't see why demanding security reductions in some acceptable model
is so onus a requirement.
If it means we are unnecessarily conservative, I'm fine making that
tradeoff. If this means that
no changes to TLS get made because no one wants to do the work to get
me to approve, I'm fine with
that. We have a working TLS ecosystem right now for some definition of
"working", namely Suite B. We still
don't have secure code implementing TLS on all CPUs.
That took 20 years, and still isn't widespread. Jeopardising that is
not worth a yet another PAKE.
>
>>> The response to #2 is that lack of implementation of these other
>>> protocols has been hampered by patents
>>
>> See the discussion around SRP that occurred when you first presented
>> this.  Any patent FUD which *might* have existed, once, has expired:
>>
>> http://www.ietf.org/mail-archive/web/tls/current/msg08203.html
>> http://www.ietf.org/mail-archive/web/tls/current/msg08191.html
>
>   Yes I am aware that the original EKE patent expired. But EKE cannot be
> used with elliptic curves. Now I know elliptic curve support is not a
> compelling use case for you but, again, so what?
>
>> Additionally, developments such as Elligator and AugPAKE hold promise
>> for protocols that have both security proofs *and* no IPR encumbrance.
>
> https://datatracker.ietf.org/ipr/2037/
Just because one particular protocol is patented does not mean others aren't.
J-PAKE is going through the CFRG, works with ECC, and has a proof. Why couldn't
you use that instead? (yes, it does incur an additional round.)
You could use a key hiding authentication system and generate a key
from a password.
You can use any multiparty equality computation protocol.
All of these are more acceptable to us than something that doesn't
even have a formal
statement of security claims, let alone a proof. What do you mean that
Dragonfly is
secure? Because for many random oracles it isn't.
>
>>> The response to #3 is: so? There is rarely uniformity in viewpoints
>>> as everyone's experience is different. Now there's a choice and if
>>> the benefits of one are not compelling then be happy you can
>>> choose the other.
>>
>> The benefits of *both* are uncompelling.  The low uptake of TLS/SRP
>> has nothing to do with this draft's cryptographic differences.  It has
>> to do with architectural issues with the approach, which your draft
>> does not improve on.
>
>   You are free to not use this protocol as well if you do not find it
> compelling.
The problem is that people faced with the choice of TLS-SRP and TLS-PWD
will not be aware of the relevant tradeoffs, and make the *wrong
choice*. The goal
of this WG is not to provide a choose your own adventure, where mistakes lead to
other people reading your passwords. There is tremendous pressure on TLS
implementations to implement objectively bad ideas that are part of
the standard,
and it is quite hard to get rid of them.

Take your financial institution, and see what gets negotiated with your browser.
And you want to give the people responsible for that more ways to
shoot themselves in the foot?
>
>   Dan.
>
>
>
> _______________________________________________
> 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 dharkins@lounge.org  Fri Dec  6 02:00:59 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD4A1AE0A8 for ; Fri,  6 Dec 2013 02:00:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 zZDIxf-CdDpH for ; Fri,  6 Dec 2013 02:00:56 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E94E81AE03F for ; Fri,  6 Dec 2013 02:00:55 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C96D51022404C; Fri,  6 Dec 2013 02:00:51 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 6 Dec 2013 02:00:52 -0800 (PST)
Message-ID: 
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>  <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net> 
Date: Fri, 6 Dec 2013 02:00:52 -0800 (PST)
From: "Dan Harkins" 
To: "Watson Ladd" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 10:00:59 -0000

On Thu, December 5, 2013 11:24 pm, Watson Ladd wrote:
> On Thu, Dec 5, 2013 at 10:40 AM, Dan Harkins  wrote:
>>
>>
>> On Thu, December 5, 2013 10:01 am, Trevor Perrin wrote:
>>> See the discussion around SRP that occurred when you first presented
>>> this.  Any patent FUD which *might* have existed, once, has expired:
>>>
>>> http://www.ietf.org/mail-archive/web/tls/current/msg08203.html
>>> http://www.ietf.org/mail-archive/web/tls/current/msg08191.html
>>
>>   Yes I am aware that the original EKE patent expired. But EKE cannot be
>> used with elliptic curves. Now I know elliptic curve support is not a
>> compelling use case for you but, again, so what?
>>
>>> Additionally, developments such as Elligator and AugPAKE hold promise
>>> for protocols that have both security proofs *and* no IPR encumbrance.
>>
>> https://datatracker.ietf.org/ipr/2037/
> Just because one particular protocol is patented does not mean others
> aren't.

  Who said otherwise? Certainly not me. But you sure got that straw man.
Good shooting!

  I was just responding to a statement that purported to mention an
unpatented protocol that not only is patented but also has a pretty nasty
licensing agreement.

> J-PAKE is going through the CFRG, works with ECC, and has a proof. Why
> couldn't
> you use that instead? (yes, it does incur an additional round.)

  I have an idea, why don't you? Work that extra round into the TLS
protocol. Write up an Internet-Draft. Seriously. Please write this up. I
can't wait to see it.

>>> The benefits of *both* are uncompelling.  The low uptake of TLS/SRP
>>> has nothing to do with this draft's cryptographic differences.  It has
>>> to do with architectural issues with the approach, which your draft
>>> does not improve on.
>>
>>   You are free to not use this protocol as well if you do not find it
>> compelling.
> The problem is that people faced with the choice of TLS-SRP and TLS-PWD
> will not be aware of the relevant tradeoffs, and make the *wrong
> choice*.

  Ahh, the voice of inexperience….

  Yes, people do make bad decisions because they don't understand all
the nuances. In the real world what they do is something stupid like a
self-signed certificate ("just check 'OK', it's alright") followed by HTTP
digest authentication. That's the good one, sometimes they just do PAP
with a self-signed certificate. Or they use a PSK cipher suite with a
simple password. When this has been exposed these companies have
responded to me, "but we're using TLS so it's secure" or "we're using AES
so it's secure". The problem is not that these people you refer do not
know  how to choose between TLS-SRP and TLS-pwd, it is that they are
not given the opportunity to use either one.

  But there are other people who can, and want to, make the right choice.
Like using TLS-pwd with ECC to authenticate to an EST server so one can
parlay a simple password/code/phrase/key into a certificate with an
ECC public key-- instead of using a 1024-bit FFC group to certify a
384-bit ECC public key it makes sense to use the same ECC group for
authentication that is used to generate the certified public key. Or
people whose small embedded devices (where hardcoding large FFC
groups is out of the question) have rudimentary UIs that limit ones
choice of credential to something simple like a password and want
to use TLS-pwd to authenticate with a central server.

> The goal
> of this WG is not to provide a choose your own adventure, where mistakes
> lead to
> other people reading your passwords. There is tremendous pressure on TLS
> implementations to implement objectively bad ideas that are part of
> the standard,
> and it is quite hard to get rid of them.

  Oh, so what you're saying is that there is now tremendous pressure to
implement TLS-pwd (an "objectively bad idea" in your opinion)?  You might
want to get with Trevor. You guys seem to be at odds over that one.

> Take your financial institution, and see what gets negotiated with your
> browser.
> And you want to give the people responsible for that more ways to
> shoot themselves in the foot?

  My financial institution will not use TLS-pwd. It won't use TLS-SRP either.
TLS-pwd is not a universal, useful-for-all situations, cipher suite. It has
a very specific set of use cases for which it is applicable and financial
institutions are not one of them.

  Which isn't to say that there are no problems with the TLS connection to
my bank. I have no relationship with  the company whose CA is used by
my bank. I've never audited the processes they use with their CA, I don't
know their disaster recovery plan. I have never met any officers in the
company and have no reason to believe they are trustworthy and not
susceptible to some form of blackmail. So actually I have no reason to
trust the certificate presented by my bank signed by their CA when I
connect to my bank's server. But my browser trusts it for me because
some industry consortium that I am not a party to vouched for it. So
if you're worried about financial institutions and how browsers connect
to them I think you have bigger concerns that TLS-pwd.

  Dan.



From codesinchaos@gmail.com  Fri Dec  6 03:14:25 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E732B1AE33C for ; Fri,  6 Dec 2013 03:14:25 -0800 (PST)
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 sB7Jq_WUxlCl for ; Fri,  6 Dec 2013 03:14:24 -0800 (PST)
Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 607E41AE347 for ; Fri,  6 Dec 2013 03:14:24 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id y10so491744wgg.24 for ; Fri, 06 Dec 2013 03:14:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=eOXVipV4BacG3ANsUExjXlmWV/Hy/jdNiFFo8JRqgd8=; b=SpVoza2Tb59P/Wp6GbyQDqinLxcsohzlmS+OIYZxRR0zlUVoh91Q99ek2Vyjg4o8O6 eXX621ixWed0XwnHeVx84OkKqkIDkxmRLJFmNEsVEEcADU5Hcj5h3VeykVxslKvVWWq/ WTdtvSnxgWk4ivpU7wOBMC159RGFXoY3z7/iw7kpM9bhAFKGDahHKDuOUgU1veCRiDnO kiZ5mgpkXGjRWay4GT3MtCA8rcQV3r29BJKmpQdeaPNZxw9v+Vz3hAzWP3r7S73f8yhE imhDt7iMhdXaEJCxYkAccz+3bmeAnikv1WzXOtaLH7T0+fDf0k8cRDiXcVuFEGyUcD7c qXng==
MIME-Version: 1.0
X-Received: by 10.194.2.108 with SMTP id 12mr2605610wjt.64.1386328460138; Fri, 06 Dec 2013 03:14:20 -0800 (PST)
Received: by 10.216.61.15 with HTTP; Fri, 6 Dec 2013 03:14:20 -0800 (PST)
In-Reply-To: <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>
Date: Fri, 6 Dec 2013 12:14:20 +0100
Message-ID: 
From: CodesInChaos 
To: Dan Harkins , "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 11:14:26 -0000

On Thu, Dec 5, 2013 at 6:15 PM, Dan Harkins  wrote:
>   No, that's not really true.  There is a difference between "your
> protocol has
> not been proven secure" and "your protocol has a security flaw". And while
> the former has been pointed out on this list and the CFRG list, the later
> has not.

How is using a password hash a hundred times weaker than md5crypt not
considered a security flaw?
Database compromises happen all the time, and forcing the server to
store a weakly hashed password
isn't acceptable IMO.

From nmav@redhat.com  Fri Dec  6 04:20:04 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51E71AE387 for ; Fri,  6 Dec 2013 04:20:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 dh9jEepXKT5u for ; Fri,  6 Dec 2013 04:20:02 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 88A551AE35C for ; Fri,  6 Dec 2013 04:20:02 -0800 (PST)
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 rB6CJpnJ028012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Dec 2013 07:19:51 -0500
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 rB6CJmWm010624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Dec 2013 07:19:50 -0500
Message-ID: <1386332388.3430.22.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Samuel Neves 
Date: Fri, 06 Dec 2013 13:19:48 +0100
In-Reply-To: <5296C6D7.2040509@dei.uc.pt>
References:  <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com> <5296C6D7.2040509@dei.uc.pt>
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
Cc: tls@ietf.org
Subject: [TLS] chacha to replace RC4 (was:  Salsa vs. ChaCha)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 12:20:05 -0000

On Thu, 2013-11-28 at 04:30 +0000, Samuel Neves wrote:
>  - Zooko has mentioned BLAKE and its success against cryptanalysis, but
> as noted this does not translate to a useful security reduction. It is
> worth pointing out, however, that cryptographers chose to base the core
> of their algorithm in the ChaCha quarter-round rather than the Salsa
> quarter-round. This suggests equal or more confidence in ChaCha (see
> also [4]).

To speed things up, we have submitted an alternative draft that replaces
RC4 with Chacha [0] instead of Salsa20. This draft is based on the 20
round variant of chacha.

We believe there are merits in selecting a winner of cryptographic
competition, but given your comments and that Chacha was the
recommendation of the CFRG there is no need to delay things if Chacha vs
Salsa20 is only issue to replace RC4.

[0]. http://www.ietf.org/id/draft-mavrogiannopoulos-chacha-tls-00.txt

regards,
Nikos



From rransom.8774@gmail.com  Fri Dec  6 04:54:13 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29CA1AE382 for ; Fri,  6 Dec 2013 04:54:12 -0800 (PST)
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 uSkML4yuPQQe for ; Fri,  6 Dec 2013 04:54:09 -0800 (PST)
Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDC51ADF9E for ; Fri,  6 Dec 2013 04:54:09 -0800 (PST)
Received: by mail-qc0-f174.google.com with SMTP id n7so402654qcx.5 for ; Fri, 06 Dec 2013 04:54:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EyebRBcZd4rfuBnw/ptLAGO0bu0ycTr1v2f2QPyW+YE=; b=SdjTc9tdZToqdGCcVWmLNfg5L7aUX80oZfGZgKXHSNWM1S5rXZqJKU7fhwSOc86IfO 9Syyq3kSoJvnrhcwPF32VJUljOQzV9puhfteeF3w8XW1aCBogs3ezpMcy4hwJmb1etEa MLnK1W6bmGER77/Fa8xiY3R0BJLxy7b1pgd5b1R+/a3zRQ7Wc9Mk1ZjE5VcP4ME/YCfw dDPzWw0kOWy3kq0gtsr0+uiBp3fmROooUDj4U/oQG3zHn+xhQ4hPMw9md9Uk0X40eLep hmjzVs2ADtTP00lK83poidSmptz0Ashr6Hk4whZhp/cwOIf3XTfnpWTul5Q1jQZFMwHu ScOQ==
MIME-Version: 1.0
X-Received: by 10.224.0.68 with SMTP id 4mr6404049qaa.17.1386334445677; Fri, 06 Dec 2013 04:54:05 -0800 (PST)
Received: by 10.229.8.3 with HTTP; Fri, 6 Dec 2013 04:54:05 -0800 (PST)
In-Reply-To: <1386332388.3430.22.camel@dhcp-2-127.brq.redhat.com>
References:  <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com> <5296C6D7.2040509@dei.uc.pt> <1386332388.3430.22.camel@dhcp-2-127.brq.redhat.com>
Date: Fri, 6 Dec 2013 04:54:05 -0800
Message-ID: 
From: Robert Ransom 
To: Nikos Mavrogiannopoulos 
Content-Type: text/plain; charset=UTF-8
Cc: tls@ietf.org
Subject: Re: [TLS] chacha to replace RC4 (was: Salsa vs. ChaCha)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 12:54:13 -0000

On 12/6/13, Nikos Mavrogiannopoulos  wrote:
> On Thu, 2013-11-28 at 04:30 +0000, Samuel Neves wrote:
>>  - Zooko has mentioned BLAKE and its success against cryptanalysis, but
>> as noted this does not translate to a useful security reduction. It is
>> worth pointing out, however, that cryptographers chose to base the core
>> of their algorithm in the ChaCha quarter-round rather than the Salsa
>> quarter-round. This suggests equal or more confidence in ChaCha (see
>> also [4]).
>
> To speed things up, we have submitted an alternative draft that replaces
> RC4 with Chacha [0] instead of Salsa20. This draft is based on the 20
> round variant of chacha.
>
> We believe there are merits in selecting a winner of cryptographic
> competition, but given your comments and that Chacha was the
> recommendation of the CFRG there is no need to delay things if Chacha vs
> Salsa20 is only issue to replace RC4.

The other issue in replacing RC4 with Salsa20 or ChaCha is that the
currently available efficient implementations of Salsa20 and ChaCha
encrypt a whole message at once, rather than incrementally generating
a stream as with RC4.  (And modifying them to do the latter would add
considerable complexity -- if it must be done, I would generate 3 or 4
blocks of output at a time and have some other piece of code XOR the
keystream with the data.)

Salsa20 and ChaCha are meant to be used as in Adam Langley's draft,
not as replacements for RC4.


Robert Ransom

From nmav@redhat.com  Fri Dec  6 05:15:06 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0F31ADFAF for ; Fri,  6 Dec 2013 05:15:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 7iDwAybnnN3z for ; Fri,  6 Dec 2013 05:15:05 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 00D391ADFAD for ; Fri,  6 Dec 2013 05:15:04 -0800 (PST)
Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rB6DExW6020413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Dec 2013 08:15:00 -0500
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rB6DEvmT020060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Dec 2013 08:14:59 -0500
Message-ID: <1386335697.3430.31.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Robert Ransom 
Date: Fri, 06 Dec 2013 14:14:57 +0100
In-Reply-To: 
References:  <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com> <5296C6D7.2040509@dei.uc.pt> <1386332388.3430.22.camel@dhcp-2-127.brq.redhat.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.25
Cc: tls@ietf.org
Subject: Re: [TLS] chacha to replace RC4 (was: Salsa vs. ChaCha)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 13:15:06 -0000

On Fri, 2013-12-06 at 04:54 -0800, Robert Ransom wrote:

> > We believe there are merits in selecting a winner of cryptographic
> > competition, but given your comments and that Chacha was the
> > recommendation of the CFRG there is no need to delay things if Chacha vs
> > Salsa20 is only issue to replace RC4.
> The other issue in replacing RC4 with Salsa20 or ChaCha is that the
> currently available efficient implementations of Salsa20 and ChaCha
> encrypt a whole message at once, rather than incrementally generating
> a stream as with RC4.  (And modifying them to do the latter would add
> considerable complexity -- if it must be done, I would generate 3 or 4
> blocks of output at a time and have some other piece of code XOR the
> keystream with the data.)

Which ones are you referring to? I have been using salsa20 with a sane
API that allows encrypting message by message (see nettle's
implementation of salsa20).

> Salsa20 and ChaCha are meant to be used as in Adam Langley's draft,
> not as replacements for RC4.

Are you suggesting that neither is good for TLS? I disagree, as if you
see my IETF88 presentation slides, Salsa20 performs much better than RC4
_in TLS_, making it suitable for a replacement.

Adam's draft proposes a novel scheme. While that this is a good scheme,
it can only be used in TLS 1.2 or later, and there will be competing
AEAD schemes coming from the CAESAR competition. We need a replacement
for RC4 now, that can (ideally) be patched in old implementations as
well.

regards,
Nikos



From nmav@redhat.com  Fri Dec  6 05:22:40 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1FE1AE388 for ; Fri,  6 Dec 2013 05:22:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 SIEgrn9_18zn for ; Fri,  6 Dec 2013 05:22:39 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id B6A561AE37D for ; Fri,  6 Dec 2013 05:22:39 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rB6DMXgk023990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Dec 2013 08:22:34 -0500
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rB6DMVpP004232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Dec 2013 08:22:32 -0500
Message-ID: <1386336151.3430.34.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Robert Ransom 
Date: Fri, 06 Dec 2013 14:22:31 +0100
In-Reply-To: 
References:  <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com> <5296C6D7.2040509@dei.uc.pt> <1386332388.3430.22.camel@dhcp-2-127.brq.redhat.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.23
Cc: tls@ietf.org
Subject: Re: [TLS] chacha to replace RC4 (was: Salsa vs. ChaCha)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 13:22:41 -0000

On Fri, 2013-12-06 at 04:54 -0800, Robert Ransom wrote:

> The other issue in replacing RC4 with Salsa20 or ChaCha is that the
> currently available efficient implementations of Salsa20 and ChaCha
> encrypt a whole message at once, rather than incrementally generating a
> stream as with RC4.  (And modifying them to do the latter would add
> considerable complexity -- if it must be done, I would generate 3 or 4
> blocks of output at a time and have some other piece of code XOR the
> keystream with the data.)
> 
> Salsa20 and ChaCha are meant to be used as in Adam Langley's draft, not
> as replacements for RC4.

Reading that again, I believe that what you say above doesn't make
sense. Why Chacha suits better in Adam's draft, but doesn't as a 
replacement of RC4?

regards, 
Nikos



From simon.gutjahr@hs-offenburg.de  Fri Dec  6 07:02:59 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC451ADFF3 for ; Fri,  6 Dec 2013 07:02:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.349
X-Spam-Level: 
X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 G1ApKPqZ3erZ for ; Fri,  6 Dec 2013 07:02:58 -0800 (PST)
Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 069441ADF6E for ; Fri,  6 Dec 2013 07:02:57 -0800 (PST)
Received: from gwia2.rz.hs-offenburg.de (gwia2.rz.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (8.13.6/8.13.6/SuSE Linux 0.8) with ESMTP id rB6F2qSf023400 for ; Fri, 6 Dec 2013 16:02:52 +0100
Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Fri, 06 Dec 2013 16:02:52 +0100
Message-Id: <52A1F52A02000078000457E3@gwia2.rz.hs-offenburg.de>
X-Mailer: Novell GroupWise Internet Agent 12.0.2 
Date: Fri, 06 Dec 2013 16:02:50 +0100
From: "Simon Gutjahr" 
To: 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part7645880A.0__="
Subject: [TLS] Changes TLS 1.1 to TLS 1.2
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 15:07:25 -0000

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part7645880A.0__=
Content-Type: multipart/alternative; boundary="=__Part7645880A.1__="

--=__Part7645880A.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello,

i haven`t followed this Working Group, so please excuse if there was =
another discussion about my question.

I`m working on an update of an existing TLS 1.1 implementation to the =
version 1.2. For this, i`m looking for a detailed list with the changes =
betweetn TLS 1.1 and TLS 1.2. Unfortunately i haven`t found such a list =
yet. In the TLS 1.2 specification is only a chapter about the major =
changes, but not about all changes.

Therefore my question: Can anyone of you provide a complete list with all =
changes between this two TLS versions? Or is there at least an easy way to =
find out the changes?

Best regards
Simon


--=__Part7645880A.1__=
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML

Hello,

i haven`t followed this Working Group, =
so please excuse if there was another discussion about my question.

=
I`m working on an update of an existing TLS 1.1 implementation to the =
version 1.2. For this, i`m looking for a detailed list with the changes =
betweetn TLS 1.1 and TLS 1.2. Unfortunately i haven`t found such a list =
yet. In the TLS 1.2 specification is only a chapter about the major =
changes, but not about all changes.

Therefore my question: Can =
anyone of you provide a complete list with all changes between this two =
TLS versions? Or is there at least an easy way to find out the changes?
=

Best regards
Simon


--=__Part7645880A.1__=--

--=__Part7645880A.0__=--

From nick.a.mathewson@gmail.com  Fri Dec  6 07:21:14 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3771AE050 for ; Fri,  6 Dec 2013 07:21:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level: 
X-Spam-Status: No, score=-0.678 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, J_CHICKENPOX_35=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 xJZG1gKncexv for ; Fri,  6 Dec 2013 07:21:13 -0800 (PST)
Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BDD9B1AE039 for ; Fri,  6 Dec 2013 07:21:12 -0800 (PST)
Received: by mail-qc0-f174.google.com with SMTP id n7so549255qcx.19 for ; Fri, 06 Dec 2013 07:21:08 -0800 (PST)
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=N488GWlRdiYmHYRRCaK/ab1Uvy8tEi5pvrM+nLvm7a8=; b=weN3DdHLTGPewJUXJnd2/ox2nwGn80cciRbYNOXKNEg6hK9BAviS9nbuwWFHQIxGx9 9JnxJThWunNoOiZn2pz4vxaBogHTdFNa5NIYNQpodnlJeIF77AOWWMNBYC0ZbWGPmfsC IcSVHb55LnhjkLURxo9ktfigMXUIQKEdsncJf0NheNuGtS7uYAsGCdk7zJ4DSdRGtMXT zi6xCnUqjou95DK71a4hUNuggKO6LTOJlV3Xi4ovpA3BrRZmF8yUM2sUQDgFslj87Rof rI7vjx2vgKtrdz6Y4Ss57GUVyVMPujTmDKtgyy7VYmH5ROZmEGGhjq6ZIZso7/q7mVQ0 LtHQ==
MIME-Version: 1.0
X-Received: by 10.49.17.196 with SMTP id q4mr7535184qed.31.1386343268673; Fri, 06 Dec 2013 07:21:08 -0800 (PST)
Sender: nick.a.mathewson@gmail.com
Received: by 10.140.102.82 with HTTP; Fri, 6 Dec 2013 07:21:08 -0800 (PST)
In-Reply-To: <1386336151.3430.34.camel@dhcp-2-127.brq.redhat.com>
References:  <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com> <5296C6D7.2040509@dei.uc.pt> <1386332388.3430.22.camel@dhcp-2-127.brq.redhat.com>  <1386336151.3430.34.camel@dhcp-2-127.brq.redhat.com>
Date: Fri, 6 Dec 2013 10:21:08 -0500
X-Google-Sender-Auth: o7LGTiMHVYrjhIFaKjoF4hKTTuw
Message-ID: 
From: Nick Mathewson 
To: Nikos Mavrogiannopoulos 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] chacha to replace RC4 (was: Salsa vs. ChaCha)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 15:21:14 -0000

On Fri, Dec 6, 2013 at 8:22 AM, Nikos Mavrogiannopoulos  wrote:
> On Fri, 2013-12-06 at 04:54 -0800, Robert Ransom wrote:
>
>> The other issue in replacing RC4 with Salsa20 or ChaCha is that the
>> currently available efficient implementations of Salsa20 and ChaCha
>> encrypt a whole message at once, rather than incrementally generating a
>> stream as with RC4.  (And modifying them to do the latter would add
>> considerable complexity -- if it must be done, I would generate 3 or 4
>> blocks of output at a time and have some other piece of code XOR the
>> keystream with the data.)
>>
>> Salsa20 and ChaCha are meant to be used as in Adam Langley's draft, not
>> as replacements for RC4.
>
> Reading that again, I believe that what you say above doesn't make
> sense. Why Chacha suits better in Adam's draft, but doesn't as a
> replacement of RC4?
>

He's saying that the existing chacha and salsa20 implementations are
designed so that, instead of generating an arbitrary-length stream
incrementally, they generate the start of the stream each time you
invoke them with a key,nonce pair, and you are supposed to choose a
new nonce each time.

As you probably know, these stream ciphers are implemented in terms of
a block function that takes as input a 256-bit key, a 64-bit nonce,
and a 64-bit counter, and produces 512 bits of output.  To generate a
stream longer than 512 bits, you hold the key and nonce fixed and let
the counter run from 0 to N until you have generated as many 512-bit
blocks as you need.

The issue is that most implementations (all the ones I've seen,
actually, and Robert has probably looked at more than I have) have an
interface where you specify the number of bytes of output up front,
and generate.  They do not have an incremental "generate the next N
bytes of the stream" function.

That said, it's pretty trivial to adopt _any_ of the implementations
I've seen so that they would run incrementally; it's not a difficult
programming problem.  You'd need to add 512 bits of memory overhead
for each chacha instance, and you'd take a little performance overhead
from the bookkeeping, but that's not a huge deal.

And *that* said, it's also trivial to avoid the need to make any such
change, by taking the strategy Adam's draft does, and using a
different nonce for each record.



hth,
-- 
Nick Mathewson

From nmav@redhat.com  Fri Dec  6 07:57:30 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B29E1AE035 for ; Fri,  6 Dec 2013 07:57:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 6OExdhW2B2L6 for ; Fri,  6 Dec 2013 07:57:28 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3102B1AE001 for ; Fri,  6 Dec 2013 07:57:28 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rB6FvMZm002082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Dec 2013 10:57:23 -0500
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rB6FvKAY028053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Dec 2013 10:57:21 -0500
Message-ID: <1386345440.29004.2.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Nick Mathewson 
Date: Fri, 06 Dec 2013 16:57:20 +0100
In-Reply-To: 
References:  <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com> <5296C6D7.2040509@dei.uc.pt> <1386332388.3430.22.camel@dhcp-2-127.brq.redhat.com>  <1386336151.3430.34.camel@dhcp-2-127.brq.redhat.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.23
Cc: "tls@ietf.org" 
Subject: Re: [TLS] chacha to replace RC4 (was: Salsa vs. ChaCha)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 15:57:30 -0000

On Fri, 2013-12-06 at 10:21 -0500, Nick Mathewson wrote:

> The issue is that most implementations (all the ones I've seen,
> actually, and Robert has probably looked at more than I have) have an
> interface where you specify the number of bytes of output up front,
> and generate.  They do not have an incremental "generate the next N
> bytes of the stream" function.
> 
> That said, it's pretty trivial to adopt _any_ of the implementations
> I've seen so that they would run incrementally; it's not a difficult
> programming problem.  You'd need to add 512 bits of memory overhead
> for each chacha instance, and you'd take a little performance overhead
> from the bookkeeping, but that's not a huge deal.

I also think so.

> And *that* said, it's also trivial to avoid the need to make any such
> change, by taking the strategy Adam's draft does, and using a
> different nonce for each record.

A different nonce for each record is mandatory if chacha or salsa20 are
to be used with DTLS. This has been the case from the first draft we had
in salsa20. So I think the previous comment is not applicable to the
draft I posted.

regards,
Nikos



From rransom.8774@gmail.com  Fri Dec  6 08:42:28 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47651AE342 for ; Fri,  6 Dec 2013 08:42:28 -0800 (PST)
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 WuYDwuHYmzua for ; Fri,  6 Dec 2013 08:42:27 -0800 (PST)
Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 91E4E1AE348 for ; Fri,  6 Dec 2013 08:42:27 -0800 (PST)
Received: by mail-qc0-f173.google.com with SMTP id m20so634875qcx.4 for ; Fri, 06 Dec 2013 08:42:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9xyLqhWdDpPZpyhGAXurU4DpGtGmgmAzNfvcYj8QYww=; b=xF6iavRDtkj95TDQIehLFxdmS/jj8s4KVvkdxIfPnvsK9FQ86wdY1py6Ffidw5Q6Gp woJ7RhcIMECcBIH8KZmfMIJPBUYkyoPWMmuARrtUv/6OIME5bgMC42MTLTXm3YLfBuDP mWMuwguomyhaNfMtfsfhTFeRAmOjfnxfzxg0TFzt2HtNMUyfJcPC4Sh0Y5PZaV/k2hsh i+VEhleKr928V01SCdPsemg9beWWxUZkUBFl783a+y8S05t8IBZ3x+QrNhV24i20RLRd LL/RYO61ChM7LOB9W/jvQpH/XX3p/Kel5GBgn1q7M+KkczTn+9qOLjkaSyFG+7JhUQyK cEsg==
MIME-Version: 1.0
X-Received: by 10.224.73.200 with SMTP id r8mr8167305qaj.72.1386348143728; Fri, 06 Dec 2013 08:42:23 -0800 (PST)
Received: by 10.229.8.3 with HTTP; Fri, 6 Dec 2013 08:42:23 -0800 (PST)
In-Reply-To: 
References:  <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com> <5296C6D7.2040509@dei.uc.pt> <1386332388.3430.22.camel@dhcp-2-127.brq.redhat.com>  <1386336151.3430.34.camel@dhcp-2-127.brq.redhat.com> 
Date: Fri, 6 Dec 2013 08:42:23 -0800
Message-ID: 
From: Robert Ransom 
To: Nick Mathewson 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] chacha to replace RC4 (was: Salsa vs. ChaCha)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 16:42:29 -0000

On 12/6/13, Nick Mathewson  wrote:

> The issue is that most implementations (all the ones I've seen,
> actually, and Robert has probably looked at more than I have) have an
> interface where you specify the number of bytes of output up front,
> and generate.  They do not have an incremental "generate the next N
> bytes of the stream" function.

Some of Dr. Bernstein's implementations in SUPERCOP do have an
incremental interface (specified by eSTREAM).  The main difficulty
with those implementations is that the interface requires callers to
encrypt an integral number of blocks with each call except the last.

Since Salsa20 and ChaCha are well known to encrypt merely by XORing
keystream into data, this could be worked around using an external
buffer, but that's an ugly piece of extra work.

> That said, it's pretty trivial to adopt _any_ of the implementations
> I've seen so that they would run incrementally; it's not a difficult
> programming problem.  You'd need to add 512 bits of memory overhead
> for each chacha instance, and you'd take a little performance overhead
> from the bookkeeping, but that's not a huge deal.

To get the performance that people expect from these stream ciphers,
one would need to buffer (at least) three or four blocks, since the
fastest implementations (Ted Krovetz's) generate three or more blocks
in parallel.


Robert Ransom

From trevp@trevp.net  Fri Dec  6 08:42:31 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0959C1AE3A8 for ; Fri,  6 Dec 2013 08:42:31 -0800 (PST)
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 MR_VDkMGWtfn for ; Fri,  6 Dec 2013 08:42:29 -0800 (PST)
Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2416D1AE348 for ; Fri,  6 Dec 2013 08:42:28 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id b13so902367wgh.30 for ; Fri, 06 Dec 2013 08:42:24 -0800 (PST)
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=/6iDWaDnx3k1ecEt489t8f5D9LAWQf3EQMkblGqlaF4=; b=bD/FFjBVXziIkD7Xo5Bsdoez3KZBACitZCqwT8hihZrrEygeF355RPcQQvlxm5oAxb Fxgmgvrb3miiRwJlp4InztFiZuvP7jFwVrBUMRuGF512ZO3avuwOgL9gp8I88FiLArum PJkfF1tOHb+NO8UcJnEBE9PJWJkKjt64G3K0xe7LiWbYm7E4mRc3ffmYuCerUxlXxjsQ 7ry6qXmChwFuuqOm144ru5bld9WCvjqjzAWycMJ3Lqrk0OiDyQ/svHdvvgQnwmRPHjqx usBNx+2mrb9xWowm6XmOqzNBQT+bRakcdvhbT22PdyYHTLT9CUZR0YleTMZ4UhrOdSIP ic0w==
X-Gm-Message-State: ALoCoQmaUB1jEAM0zkNQpAk4bZ51MvqgDQ7NtQZXZQyK1O7/fIzKt/MguYZEhVspLKlEjZYrkf34
MIME-Version: 1.0
X-Received: by 10.180.74.7 with SMTP id p7mr2174277wiv.20.1386348144760; Fri, 06 Dec 2013 08:42:24 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Fri, 6 Dec 2013 08:42:24 -0800 (PST)
X-Originating-IP: [199.83.223.81]
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>  <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net>  
Date: Fri, 6 Dec 2013 08:42:24 -0800
Message-ID: 
From: Trevor Perrin 
To: Dan Harkins 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 16:42:31 -0000

On Fri, Dec 6, 2013 at 2:00 AM, Dan Harkins  wrote:
>
>
> On Thu, December 5, 2013 11:24 pm, Watson Ladd wrote:
>> On Thu, Dec 5, 2013 at 10:40 AM, Dan Harkins  wrote:
>>>
>>>
>>> On Thu, December 5, 2013 10:01 am, Trevor Perrin wrote:
>>>> See the discussion around SRP that occurred when you first presented
>>>> this.  Any patent FUD which *might* have existed, once, has expired:
>>>>
>>>> http://www.ietf.org/mail-archive/web/tls/current/msg08203.html
>>>> http://www.ietf.org/mail-archive/web/tls/current/msg08191.html
>>>
>>>   Yes I am aware that the original EKE patent expired. But EKE cannot be
>>> used with elliptic curves. Now I know elliptic curve support is not a
>>> compelling use case for you but, again, so what?
>>>
>>>> Additionally, developments such as Elligator and AugPAKE hold promise
>>>> for protocols that have both security proofs *and* no IPR encumbrance.
>>>
>>> https://datatracker.ietf.org/ipr/2037/
>> Just because one particular protocol is patented does not mean others
>> aren't.
>
>   Who said otherwise? Certainly not me. But you sure got that straw man.
> Good shooting!
>
>   I was just responding to a statement that purported to mention an
> unpatented protocol that not only is patented but also has a pretty nasty
> licensing agreement.

I disagree, AugPAKE's IPR declaration is reasonable.

One might wish that it covered broader uses, besides just
standards-track TLS implementations.

However, within that case, the terms are clearly "royalty-free".


Trevor

From mpg@elzevir.fr  Fri Dec  6 08:44:07 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4028B1AE385 for ; Fri,  6 Dec 2013 08:44:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.251
X-Spam-Level: 
X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-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 k8ptiScxUYbh for ; Fri,  6 Dec 2013 08:44:05 -0800 (PST)
Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) by ietfa.amsl.com (Postfix) with ESMTP id F2E531ADFFB for ; Fri,  6 Dec 2013 08:44:04 -0800 (PST)
Received: from thue.elzevir.fr (unknown [IPv6:2a01:e35:8a5d:80b0:be5f:f4ff:fe2c:95bc]) by mordell.elzevir.fr (Postfix) with ESMTPS id 942F2161DA for ; Fri,  6 Dec 2013 17:44:00 +0100 (CET)
Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id E10E42984E for ; Fri,  6 Dec 2013 17:43:57 +0100 (CET)
Message-ID: <52A1FECD.6080405@elzevir.fr>
Date: Fri, 06 Dec 2013 17:43:57 +0100
From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
To: "tls@ietf.org" 
References:  <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com> <5296C6D7.2040509@dei.uc.pt> <1386332388.3430.22.camel@dhcp-2-127.brq.redhat.com>  <1386336151.3430.34.camel@dhcp-2-127.brq.redhat.com>  <1386345440.29004.2.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1386345440.29004.2.camel@dhcp-2-127.brq.redhat.com>
X-Enigmail-Version: 1.6
OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] chacha to replace RC4
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 16:44:07 -0000

On 06/12/2013 16:57, Nikos Mavrogiannopoulos wrote:
> A different nonce for each record is mandatory if chacha or salsa20 are
> to be used with DTLS. This has been the case from the first draft we had
> in salsa20. So I think the previous comment is not applicable to the
> draft I posted.
> 
I agree, but perhaps the draft could state that more clearly.

RFC 5246 6.2.3.1 states that

    For stream ciphers that do not use a synchronization vector (such as
    RC4), the stream cipher state from the end of one record is simply
    used on the subsequent packet.

The draft may recall this to emphasize and constrast that Chacha does
use a "synchronisation vector" (the per-record nonce) so that the stream
cipher state from the end of one record is *not* used on the subsequent
packet.

Also, maybe it's just me, but maybe the draft should state explicitly
that the per-record nonce is not meant to be transmitted as part of the
GenericStreamCipher PDU, but computed as mentionned in section 2.1.

Manuel.

From mrex@sap.com  Fri Dec  6 10:25:37 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6601ADEB4 for ; Fri,  6 Dec 2013 10:25:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.152
X-Spam-Level: 
X-Spam-Status: No, score=-5.152 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 l3DsNgqaSGDD for ; Fri,  6 Dec 2013 10:25:35 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CF26A1AD8F9 for ; Fri,  6 Dec 2013 10:25:34 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rB6IPRZn011728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Dec 2013 19:25:27 +0100 (MET)
In-Reply-To: 
To: Bodo Moeller 
Date: Fri, 6 Dec 2013 19:25:27 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20131206182527.98EA51AB3C@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
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, 06 Dec 2013 18:25:37 -0000

Bodo Moeller wrote:
> 
> We can start to use TLS_FALLBACK_SCSV
> ASAP to improve security *ASAP* for connections to *those* servers that do
> get updated (80% or even just 10% is better than 0% -- if only the most
> important servers that users trust get updated, that's something).

Huh?  Your proposal is not going to improve the security one single bit.

Either the handshake goes through as initially proposed
(no TLS_FALLBACK_SCSV present in ClientHello), and therefore there can
not possibly be any improvement (or any effect).

Or the client's heuristics on network connectivity or handshake failure
from a connection attempt will result in an app-level reconnect fallback
to kick in and a new connection attempt with a more conservative ClientHello
with TLS_FALLBACK_SCSV asserted.  Either that handshake will succeed
as proposed (as if TLS_FALLBACK_SCSV wasn't present), or the handshake
will fail.

So the use of the TLS_FALLBACK_SCSV will either *NOT* affect the rest
of the TLS protocol not at all, or cause a fatal handshake failure.
And very few, if any at all, of the situations where the handshake fails,
will be instances of an active attack.  And it remains extremely
questionable, when the handshake would succeed, that the attacker
will gain anything at all.


I really do not see any benefit for servers to adopt support for this
interoperability problem.


For this feature to work at all, the prerequisite is that both communication
peers must be updated.  When looking at a protocol feature that requires
both communication peers to be updated as a prerequisite, wouldn't it be
preferable to fix those protocol features of SSL/TLS that we deem necessary
for reliable security to become negotiable even in the "most conservative"
ClientHello that clients are willing to fallback to?  This would make
the TLS handshake immune to "version downgrade" attacks  and allow
programmatic clients to offer TLS features (and cipher suites) that are
artificially and needlessly curtailed to the TLSv1.2 version number right
now to be negotiatiable in conservative ClientHellos.
This would completely obviate the fragile and complex app-level reconnect
fallback logic that is currently necessary to cope with failed TLS
handshakes caused by version-intolerant servers and dense middle boxes.


-Martin

From dharkins@lounge.org  Fri Dec  6 10:29:27 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822121AE09E for ; Fri,  6 Dec 2013 10:29:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 EZw2kBdA8-wq for ; Fri,  6 Dec 2013 10:29:25 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E2FDC1ADEB4 for ; Fri,  6 Dec 2013 10:29:25 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id ECD431022404C; Fri,  6 Dec 2013 10:29:21 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 6 Dec 2013 10:29:22 -0800 (PST)
Message-ID: <768aa9c26985fe3d3a237244954b3261.squirrel@www.trepanning.net>
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>    <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net>  <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net>  <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net> 
Date: Fri, 6 Dec 2013 10:29:22 -0800 (PST)
From: "Dan Harkins" 
To: "CodesInChaos" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 18:29:27 -0000

On Fri, December 6, 2013 3:14 am, CodesInChaos wrote:
> On Thu, Dec 5, 2013 at 6:15 PM, Dan Harkins  wrote:
>>   No, that's not really true.  There is a difference between "your
>> protocol has
>> not been proven secure" and "your protocol has a security flaw". And
>> while
>> the former has been pointed out on this list and the CFRG list, the
>> later
>> has not.
>
> How is using a password hash a hundred times weaker than md5crypt not
> considered a security flaw?

  It's not. A password hash that's 100x weaker than md5crypt would be a
security flaw.

> Database compromises happen all the time, and forcing the server to
> store a weakly hashed password
> isn't acceptable IMO.

  You're absolutely right, that would not be acceptable.

  TLS-pwd uses HMAC-SHA256 with a 32 byte random key (salt) to
hash passwords that the server stores.

  Dan.



From agl@google.com  Fri Dec  6 10:33:30 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BA81ADE84 for ; Fri,  6 Dec 2013 10:33:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 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.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 RS183HgMoqgk for ; Fri,  6 Dec 2013 10:33:29 -0800 (PST)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EE6891AC828 for ; Fri,  6 Dec 2013 10:33:28 -0800 (PST)
Received: by mail-ve0-f171.google.com with SMTP id pa12so1202309veb.16 for ; Fri, 06 Dec 2013 10:33:24 -0800 (PST)
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=H4v+JDcWcG3UfFF+Oks1n3R55IkILfEUJxzeQj/CQF4=; b=B65vGAd4gnnriqS43hQCyEqAomCUhRRKMZWiURfm2PnSWi1axwj/hYF6CE+WPukJrn xjbAVOHnF+o5OyPyL2VvXmsOiZzSuide6mQTZaMulzDxzyylGsDsTJVmNwysZgXg/rs3 pP5uBC5SKYVCy9KWzEbTpykkukz0ZFauNJSA/ekyLhv4MZBCDacuq1aPtSx3QxSxITdk jm5jYfFKuQyuQxDv4lgivabO4MKcfq00PBYbwQ62BbpeR0Ool5g0YFsoqk7FJOXxqYvU jiGUNX2nNdp4bhGxjKb9PafnhVr7We9ehbO1QmINp0vwqJ8dIdrv1MY+YuDwZKHqjGII sFkw==
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=H4v+JDcWcG3UfFF+Oks1n3R55IkILfEUJxzeQj/CQF4=; b=fwC5CiyepPbdhIcnZaD5cLakxg4X+Ylv8cQcAfS3YAKj0bjco0tVDSNIomEXydwBxq Vwl//++p3BT9JV22QWL5uh5y0CjggjzKgkQaKAjlAo0M0shBDYbLPqZWY4rboQglattT f+zuherv/LJrruz9v1koGepXc7j0V0t71zcwNykN7fPAGVVEYNRg0CGMi208aPLgu+K4 EliQfW4vglg8cXg2uDf3d7EfQpT2EaHlx5J08FbbwX7qy94q7kk2b1TcUHagKf1lWpGb CKakpTp+8KncWdEz715Zk7uEHM9tuwc/EeYrnCOM7sTYoCw5LEP4ZO9q/0aowbpWXQXy mhgQ==
X-Gm-Message-State: ALoCoQluelO19dgd8KgNLEd6vg+hMii/9hcC1B48q5il6y44Ge0QYdw3zOxIvVaL3Hddsbc0fJFfvtX60Z+OPs1zZC5VwT5nixAg36sBhtJoR28VZ4RvpnwfVXvYYUo55AZjl54MM1+YMXFnQZ986GRgkchOBRsRRcYmqwJNBiR6P3yOxAPJpsmazkaOjIUhMGL8pTynGmSQ
X-Received: by 10.221.66.132 with SMTP id xq4mr1835331vcb.57.1386354804757; Fri, 06 Dec 2013 10:33:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Fri, 6 Dec 2013 10:33:04 -0800 (PST)
In-Reply-To: <20131206182527.98EA51AB3C@ld9781.wdf.sap.corp>
References:  <20131206182527.98EA51AB3C@ld9781.wdf.sap.corp>
From: Adam Langley 
Date: Fri, 6 Dec 2013 13:33:04 -0500
Message-ID: 
To: mrex@sap.com
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 18:33:30 -0000

On Fri, Dec 6, 2013 at 1:25 PM, Martin Rex  wrote:
> For this feature to work at all, the prerequisite is that both communication
> peers must be updated.  When looking at a protocol feature that requires
> both communication peers to be updated as a prerequisite, wouldn't it be
> preferable to fix those protocol features of SSL/TLS that we deem necessary
> for reliable security to become negotiable even in the "most conservative"
> ClientHello that clients are willing to fallback to?

Fallback behaviour is needed for wide variety of buggy servers,
including those that are intolerant to unknown extensions.

I don't believe that there's a ClientHello format that is both devoid
of compat issues and sufficiently expressive to be able to negotiate
what we need now and in the future.


Cheers

AGL

From dkg@fifthhorseman.net  Fri Dec  6 10:45:43 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86EA1AE111 for ; Fri,  6 Dec 2013 10:45:43 -0800 (PST)
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 1q6pw1YrKe2F for ; Fri,  6 Dec 2013 10:45:41 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CC60A1AE087 for ; Fri,  6 Dec 2013 10:45:41 -0800 (PST)
Received: from [192.168.23.229] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 7941BF984 for ; Fri,  6 Dec 2013 13:45:36 -0500 (EST)
Message-ID: <52A21B4B.2000301@fifthhorseman.net>
Date: Fri, 06 Dec 2013 13:45:31 -0500
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
To: IETF TLS WG 
References: <20131206182527.98EA51AB3C@ld9781.wdf.sap.corp>
In-Reply-To: <20131206182527.98EA51AB3C@ld9781.wdf.sap.corp>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FNVI5LqWPlJAchxpwU9IP9eUCRq0gUDHf"
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 18:45:44 -0000

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

On 12/06/2013 01:25 PM, Martin Rex wrote:
> So the use of the TLS_FALLBACK_SCSV will either *NOT* affect the rest
> of the TLS protocol not at all, or cause a fatal handshake failure.
> And very few, if any at all, of the situations where the handshake fail=
s,
> will be instances of an active attack.

This is probably also true of X.509 certificate validation failure as
well, since there are more self-signed or expired certificates in active
use than there are active MITM attackers.  Are you suggesting that TLS
would be better off not checking certificate validity?

> And it remains extremely
> questionable, when the handshake would succeed, that the attacker
> will gain anything at all.

What the attacker can gain presumably depends on what features the
client is willing to sacrifice during fallback.  Presumably, the client
gives up specific features of the newer versions: e.g. AEAD, when
falling back below TLS 1.2, or possibly all TLS extensions for fallback
all the way to SSLv3 (to accomodate old extension-intolerant SSLv3 server=
s).

It looks like you're saying that none of these more modern features are
useful tools in defending against an active attacker.  Do you really
think that?

	--dkg


--FNVI5LqWPlJAchxpwU9IP9eUCRq0gUDHf
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.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQJ8BAEBCgBmBQJSohtLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcIPMP/j6GvrvUAD8R3LLTcennBrR3
RTj5PxObGbxg6BlJ3/LJefrJm70eabPH1ZVaRFCNvJYrYZeP6t8WQzHuXtYpQ36d
0dzNn4eGQkWeRyqim07t4MFuHiHdwBsZJ1YtkYu0n+X79Pvo+1H0umy8iKWsZiA1
h1kzagQ+h4kytCRfmrMgdJmd19nCburFqnIy8emTKhEKddHuUKe/C0XMYcmJ+VOw
Tfibz26rTOLNvQ5OT39n/xUKjiCzJZ3VwlWN93TsYtVxtM9F2ThedHJHhZQqkpiT
pBNEvKfp/jMI89YQfFyh3fdMuWTZVyu+pd3RuoY71coOgd0qIDRqZgpFsG8lFMtE
RrzNnF+X57OtuUqlczAG0mMTQo+q3r2fa3G7AlEvIisrFcBnrVyly4g6gblasbPe
szKSywf20SwJxMeZRMhn50R9ARxM6ogF2Ntq5imldzoBZTnAeMUvON1kmDOww1Ug
WTHXSK7CCxVPB1bUut+MUOLL71QgRa+1QL4wNWTUS9R6cyXk1rclrE69ghcSkUd7
bPT53H9HhpFz/jwtJPNGQ0Ps3XX3X0Xz4bHLZ1/rRqUlov7N1zgkxrJ+Y+Jb20Pc
5wXYF7xKdf0kJswfMlvvrwFyCFBl5QzMJUgJTTQfFNjI9RdnKi8ZcpJ+mzDBMpLF
CtM100m/DTjVNOPpYbPk
=FfU6
-----END PGP SIGNATURE-----

--FNVI5LqWPlJAchxpwU9IP9eUCRq0gUDHf--

From wtc@google.com  Fri Dec  6 11:59:26 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E5F1AE06F for ; Fri,  6 Dec 2013 11:59:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 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.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 0Gdgkq1lGarZ for ; Fri,  6 Dec 2013 11:59:24 -0800 (PST)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id C21BA1AE074 for ; Fri,  6 Dec 2013 11:59:24 -0800 (PST)
Received: by mail-vc0-f176.google.com with SMTP id lf12so1209673vcb.21 for ; Fri, 06 Dec 2013 11:59:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ECj0VQq7ynqIw0yP2Nf9wV82PFwMjDTQN5mph9zXfBk=; b=k8vMVo1Og5dbcAnqR1iTcmmmxba1+9K0QgGe0QlDpF5cMN58bZsLx57eLIX33T8P+9 0I1NQyzR+jr4P5U1vlOJDxt2nJ8H54wSI6iCDhuY01w2ui8zVlLW8DY1tvVfTS9qSZz/ 9ZWfvHgn1JlqpeK9hN2jpmnFRvcWDlzbqYKo1i5LgS44CB0Y/0LRKGzcdv5PBpr0D2dZ NiirsUmR0TdhxAk5Bp39oNHsYYaeTExrelrsvAElyzgIfNcy6SCXGHMtdd/L4W2gCAu1 bKoKx7fh4UeW/L3BkKXAZTWKemFwemgZolT/GJiBca+Eswa9Q/oifK+5Zck8vhxgCplI DG2A==
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=ECj0VQq7ynqIw0yP2Nf9wV82PFwMjDTQN5mph9zXfBk=; b=RAMV3qZZrLa54smL41f/oWkV1htAkUDUpqxmpnPA9nN2lF1HIkdEvZbKTqQ/8RBR73 PIB4AbL5C7xDH/H0HiboWt7mdhM9oCwju/eJZGF/cBmy/IRNbPVyI5bkO67RDEk/1Po4 2BVORvwAgnfcsp53z1upSuBYkM8xnWQ4ZuxK6/lWMwiftfB1mvv+LtY0t1GihjZwRXqf weZmPPnHIfcaQT7yIgMivaMQqDa1g+AhKHduwJGV3d2SD8s7AwqsG/ICBQ6EUnof62CQ IZCj8dKInu7SzGi33VU4eDMLZMB8L93EUnIATbNbQG10Owbl+pcCoGLW66FiuWtAMhRf EidA==
X-Gm-Message-State: ALoCoQk7SlFJG0zlol/K/LaMZ8TxU9YGZnWi9aQXZGILDCU0SpArLVfmRLb7qGYXJDiwfQ5j2MkWs3AspbgjNwPMYiSBNLTxdY5XyrY2mWHVbc2yzQLPH53LOdPDqaS6f05XK4hZPjTdW1jc4FL+bNWgH2YUmN3CMXNImUqieYscB5ZmTH3l5s+gl5kF9DNtWWhIvfLm4DBB
MIME-Version: 1.0
X-Received: by 10.52.249.3 with SMTP id yq3mr2634425vdc.55.1386359960690; Fri, 06 Dec 2013 11:59:20 -0800 (PST)
Received: by 10.52.167.10 with HTTP; Fri, 6 Dec 2013 11:59:20 -0800 (PST)
In-Reply-To: 
References: 
Date: Fri, 6 Dec 2013 11:59:20 -0800
Message-ID: 
From: Wan-Teh Chang 
To: Nick Mathewson , Adam Langley , Eric Rescorla 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 19:59:27 -0000

Sorry about my late reply. I am a programmer working on the NSS crypto
libraries. While reviewing recent changes to NSS, I noticed that
Nick's proposal 1 has been implemented in the OpenSSL and NSS source
code repositories, which led me to this old email thread.

The only protocol feature I know of that uses the gmt_unix_time field
of ClientHello.random is Adam Langley's TLS Snap Start Internet-Draft
[1]. See Section 3 of Adam's draft. This method is one of the
anti-reply mechanisms being considered in Eric Rescorla's TLS 1.3 new
handshake flows Internet-Draft [2], and is being used in the QUIC
protocol.

So, I'd like to offer another proposal:

PROPOSAL 4:

Add a random clock skew to the current time. For example, generate a
random signed integer in the interval [-512, 511] (inclusive) and add
it to the return value of time(). This adds roughly a +/-8.5 minutes
skew to the current time.

If this proposal is an acceptable solution to the client
fingerprinting problem, then gmt_unix_time in ClientHello.random will
remain viable as part of an anti-reply mechanism for TLS 1.3 new
handshake flows.

Wan-Teh Chang

[1] http://tools.ietf.org/html/draft-agl-tls-snapstart-00
[2] http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00

From brian@briansmith.org  Fri Dec  6 12:14:46 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824731AE3A2 for ; Fri,  6 Dec 2013 12:14:46 -0800 (PST)
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 MCh_JCb-2MPW for ; Fri,  6 Dec 2013 12:14:44 -0800 (PST)
Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 745251AE3B9 for ; Fri,  6 Dec 2013 12:14:44 -0800 (PST)
Received: by mail-qe0-f48.google.com with SMTP id gc15so925476qeb.7 for ; Fri, 06 Dec 2013 12:14:40 -0800 (PST)
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=UkLfF5IIM1/Bic3B29ODJbX5/00dqQh7M0jZJ44nuLU=; b=RIF/MLk4R7UaiZdJHVrwcu99SEziubr+RiMj92ITiWkA5UtYlXX7QyCwulBMsF8iL8 5adYaPQf/0WIIHdcj2U0AYPUI8g0jp9Bid7CmpM/1LVHjZxcZd2KTURp4Z9gCzJC9EqF ZCiN9p0IsHOOXcooKYcB3CvJCaAMAm7SRukGAdBnV1ti7ZoMy1J0M+yJWJ5YgtH51OjF o7j7IttiwXbxCwlyZ0N6b2HfKl8Z8tNrB/bmdjmo6oJq7GlmyIbWDbnSMe0zNQ9r228Z uJNAxQKK+612sBf7Y+PzRtrY3gcnzpEY48lTlGGbKn+SdnHZzZO1renKgK/Vh4kPP3Cf kWmA==
X-Gm-Message-State: ALoCoQkxCx1b3Tlt7+JBzWYD/TzZWHPANnTJ/6KvMxZcKRAEMBl8E6vLud4szUZLzFxtLiminsqU
MIME-Version: 1.0
X-Received: by 10.49.132.65 with SMTP id os1mr143314634qeb.39.1386360880551; Fri, 06 Dec 2013 12:14:40 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Fri, 6 Dec 2013 12:14:40 -0800 (PST)
X-Originating-IP: [12.216.141.3]
In-Reply-To: 
References:  
Date: Fri, 6 Dec 2013 12:14:40 -0800
Message-ID: 
From: Brian Smith 
To: Wan-Teh Chang 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 20:14:46 -0000

On Fri, Dec 6, 2013 at 11:59 AM, Wan-Teh Chang  wrote:
> PROPOSAL 4:
>
> Add a random clock skew to the current time. For example, generate a
> random signed integer in the interval [-512, 511] (inclusive) and add
> it to the return value of time(). This adds roughly a +/-8.5 minutes
> skew to the current time.

When the server tells the client that it supports the 0-RTT handshake
scheme, can't the server also tell the client what time the server
things it is? Then the client could calculate the offset between its
local perception of the time and the server's perception of the time,
and apply that offset to whatever timestamp it sends in its 0-RTT
handshake.

Also, timestamps is only needed for the 0-RTT handshake, handshakes
that aren't attempting to be 0-RTT shouldn't include a timestamp. So,
the timestamps should probably be moved to the extension that
negotiates the 0-RTT handshake. That way, the fingerprinting risk,
whatever it is, is limited to applications that are actually trying to
use that feature, and applications/servers that are especially
sensitive to fingerprinting (e.g. the Tor Browser) may cleanly avoid
the issue by disabling 0-RTT handshake support, as a worst-case
option.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

From stephen.farrell@cs.tcd.ie  Fri Dec  6 12:16:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7681AE167 for ; Fri,  6 Dec 2013 12:16:51 -0800 (PST)
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, RP_MATCHES_RCVD=-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 3a6RB1EjM_Ap for ; Fri,  6 Dec 2013 12:16:49 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 76EB61AE107 for ; Fri,  6 Dec 2013 12:16:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 27CDABEE9; Fri,  6 Dec 2013 20:16:45 +0000 (GMT)
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 oxzNc8pm9KLs; Fri,  6 Dec 2013 20:16:43 +0000 (GMT)
Received: from [10.87.48.12] (unknown [86.44.77.181]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7626ABEE8; Fri,  6 Dec 2013 20:16:43 +0000 (GMT)
Message-ID: <52A230A1.2000606@cs.tcd.ie>
Date: Fri, 06 Dec 2013 20:16:33 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Brian Smith , Wan-Teh Chang 
References:   
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 20:16:51 -0000

This [1] is probably also relevant.

S

[1] http://datatracker.ietf.org/doc/draft-mathewson-no-gmtunixtime/

On 12/06/2013 08:14 PM, Brian Smith wrote:
> On Fri, Dec 6, 2013 at 11:59 AM, Wan-Teh Chang  wrote:
>> PROPOSAL 4:
>>
>> Add a random clock skew to the current time. For example, generate a
>> random signed integer in the interval [-512, 511] (inclusive) and add
>> it to the return value of time(). This adds roughly a +/-8.5 minutes
>> skew to the current time.
> 
> When the server tells the client that it supports the 0-RTT handshake
> scheme, can't the server also tell the client what time the server
> things it is? Then the client could calculate the offset between its
> local perception of the time and the server's perception of the time,
> and apply that offset to whatever timestamp it sends in its 0-RTT
> handshake.
> 
> Also, timestamps is only needed for the 0-RTT handshake, handshakes
> that aren't attempting to be 0-RTT shouldn't include a timestamp. So,
> the timestamps should probably be moved to the extension that
> negotiates the 0-RTT handshake. That way, the fingerprinting risk,
> whatever it is, is limited to applications that are actually trying to
> use that feature, and applications/servers that are especially
> sensitive to fingerprinting (e.g. the Tor Browser) may cleanly avoid
> the issue by disabling 0-RTT handshake support, as a worst-case
> option.
> 
> Cheers,
> Brian
> 

From trevp@trevp.net  Fri Dec  6 12:26:23 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494581AE0C5 for ; Fri,  6 Dec 2013 12:26:23 -0800 (PST)
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=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 9eI0sFgy3J_y for ; Fri,  6 Dec 2013 12:26:20 -0800 (PST)
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF0F1AE074 for ; Fri,  6 Dec 2013 12:26:20 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id q58so1177278wes.19 for ; Fri, 06 Dec 2013 12:26:16 -0800 (PST)
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=PYUHsRqZPNYk1sTamy86wSd6F0lNUU1uPI1GY+IaLY8=; b=Gjfy+xj6QVD1zZP0eUy3i1ct41qZG/nD5eA82fvycciTPxgyVatsITobqupz2e+6oa /N6vju/1ajlwk2m1WlbZRLNxCoPZRUf0c0VvqzoxEVzqMVwkLc6c71CtjB/3LMLZAyQV hjKlieW9Vo1W08ylBbHGTq57EmwXcs8Z7IToZ6Gdaqe8MmUM1xDo2f7To4u2jsFVlyQG slwa1/4DV8eE+7s12G3GNRhk7Xw8qooMawBmlHzyVBtUT8VJKBaPEZ7ICLiUV78HLhlC jD5AXmFIyuoeVuHUSnIuZTYjp279/r09fypBuck/LWE2hw0W2g6e4rcLyIi/0rIGETgm gfwA==
X-Gm-Message-State: ALoCoQl6yuT/ky/WryjMZy1rNg4ARg6h2JdOj5zRtUHxsEjBSa/L7GugYb+pGPTMlCToaZnWtdiN
MIME-Version: 1.0
X-Received: by 10.194.142.142 with SMTP id rw14mr5162975wjb.87.1386361575765;  Fri, 06 Dec 2013 12:26:15 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Fri, 6 Dec 2013 12:26:15 -0800 (PST)
X-Originating-IP: [64.134.226.64]
In-Reply-To: 
References: <20130906074540.19067.67943.idtracker@ietfa.amsl.com> 
Date: Fri, 6 Dec 2013 12:26:15 -0800
Message-ID: 
From: Trevor Perrin 
To: SeongHan Shin 
Content-Type: text/plain; charset=ISO-8859-1
Cc: =?UTF-8?B?5Y+k5Y6f5ZKM6YKm?= , cfrg@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] I-D Action: draft-irtf-cfrg-augpake-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: Fri, 06 Dec 2013 20:26:23 -0000

I really like this idea & can find no problems.

Since a single cursory opinion counts for CFRG consensus [1,2],
consider this approved by CFRG and our NSA overseers.

Thanks, come again!


Trevor


P.S. The treatment of random numbers could be improved, consider
referencing NIST SP 800-90A.

(psst Kevin ^^^ THIS is how it's done.  *FINESSE*, or you'll never
work the big leagues!)


[1] http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html
[2] http://www.ietf.org/proceedings/84/minutes/minutes-84-tls


On Sun, Sep 29, 2013 at 11:18 PM, SeongHan Shin
 wrote:
> Dear all,
>
> We submitted our I-D regarding augmented PAKE
> that provides extra protection to server compromise compared to balanced
> PAKE.
> (Of course, it can be easily converted to the balanced one)
>
> Any comments are welcome!
>
> Best regards,
> Shin
>
>
> On Fri, Sep 6, 2013 at 4:45 PM,  wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>  This draft is a work item of the Crypto Forum Research Group Working
>> Group of the IETF.
>>
>>         Title           : Augmented Password-Authenticated Key Exchange
>> (AugPAKE)
>>         Author(s)       : SeongHan Shin
>>                           Kazukuni Kobara
>>         Filename        : draft-irtf-cfrg-augpake-00.txt
>>         Pages           : 17
>>         Date            : 2013-09-06
>>
>> Abstract:
>>    This document describes a secure and highly-efficient augmented
>>    password-authenticated key exchange (AugPAKE) protocol where a user
>>    remembers a low-entropy password and its verifier is registered in
>>    the intended server.  In general, the user password is chosen from a
>>    small set of dictionary whose space is within the off-line dictionary
>>    attacks.  The AugPAKE protocol described here is secure against
>>    passive attacks, active attacks and off-line dictionary attacks (on
>>    the obtained messages with passive/active attacks).  Also, this
>>    protocol provides resistance to server compromise in the context that
>>    an attacker, who obtained the password verifier from the server, must
>>    at least perform off-line dictionary attacks to gain any advantage in
>>    impersonating the user.  The AugPAKE protocol is not only provably
>>    secure in the random oracle model but also the most efficient over
>>    the previous augmented PAKE protocols (SRP and AMP).
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-irtf-cfrg-augpake
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-irtf-cfrg-augpake-00
>>
>>
>> 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/
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
>
>
>
>
> --
> ------------------------------------------------------------------
> SeongHan Shin
> Research Institute for Secure Systems (RISEC),
> National Institute of Advanced Industrial Science and Technology (AIST),
> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
> Tel : +81-29-861-2670/5284
> Fax : +81-29-861-5285
> E-mail : seonghan.shin@aist.go.jp
> ------------------------------------------------------------------
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>

From wtc@google.com  Fri Dec  6 12:38:04 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742081AE19C for ; Fri,  6 Dec 2013 12:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 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.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 v_VaVHX1OVZo for ; Fri,  6 Dec 2013 12:38:03 -0800 (PST)
Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7BB1AE191 for ; Fri,  6 Dec 2013 12:38:02 -0800 (PST)
Received: by mail-ve0-f174.google.com with SMTP id pa12so1377017veb.19 for ; Fri, 06 Dec 2013 12:37:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Eottfo+eXr10nUdFYkxa2T9NxnCVXWB4+8QCjNs54B0=; b=LieSV457nwn0/O+EAy/SFHbslOyoCHGFpSaE5aFrssoABRoAHkztzp0Ab5/x/njN93 uPYD4yHvvgWqdYPZHpa1x5WMJuwMlzUOY7ZpN9Pnd9VYBv7Li1sDLoMdprRg77C8h/Sj zg6WHqUqd1qEAgCYqT/OXNMoTRnDZ1k9qTrmXyisuWz/ELnAJW/0zC/8uddiAt+aNqdT OLDJjU0ks2EPgiLZyr/E9xWLBpGasBf87iHLzqojrTEG60Ds6GYqiriLOXwufL/PN9nB Euj/sKimtDtZlbor39zhOhrTxpkRu7uiXodtO1TMm/gpTsn2lvAuRBC1f9oqx753V5VA H/yg==
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=Eottfo+eXr10nUdFYkxa2T9NxnCVXWB4+8QCjNs54B0=; b=kVgNkDgJM+YiUUBahfbX+7PO7MHMjnbhqnaxPJNOWqGT8HFJVFtZUzx/9W0FH4ouZT T3IcJh1Ejyz/PD8hJWpGUbKgS4oxHeUFKRgg/Cna0Jx09r/WnK5M7R3VDkDCBCF1A7IO CfuE4aKDtKwmHak2uMns7ujRv4x8yppBR6/SbG+IXjdESWqXQggn7Uj0heM2kKiF0yBQ olk7beNCFNMD9/qh0H5YILpBsWK1KPlZzq+0NJWIulKw5uL1vgLD0B3J0UjIS5aCAltn csph+FAcxkbE1Bn0iXhdv57bmLXLLVQ2wOkkIgmdzjqTkgRTEGaYxSu9ciykRx4Xhl+t pAeQ==
X-Gm-Message-State: ALoCoQnEcH6V0iavsvPs/GwDFxp++oLl2TyN3D9CLs2Gpim+s3Rgwo06udimzKOWm4scPIrT0rL3eqgiv9e4FBOpUcxq7XmH/vpcQJbRjAkkXG6AlbKHRGXhCjNjJJenhdztjflMzvemWMamiA48pkv8MyMcoNVtIkXELz2Ir6xu3ddITedyOiDiINiHfL5/ZNhwcwB43LnM
MIME-Version: 1.0
X-Received: by 10.58.143.17 with SMTP id sa17mr2997983veb.14.1386362278915; Fri, 06 Dec 2013 12:37:58 -0800 (PST)
Received: by 10.52.167.10 with HTTP; Fri, 6 Dec 2013 12:37:58 -0800 (PST)
In-Reply-To: 
References:   
Date: Fri, 6 Dec 2013 12:37:58 -0800
Message-ID: 
From: Wan-Teh Chang 
To: Brian Smith 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 20:38:04 -0000

On Fri, Dec 6, 2013 at 12:14 PM, Brian Smith  wrote:
> On Fri, Dec 6, 2013 at 11:59 AM, Wan-Teh Chang  wrote:
>> PROPOSAL 4:
>>
>> Add a random clock skew to the current time. For example, generate a
>> random signed integer in the interval [-512, 511] (inclusive) and add
>> it to the return value of time(). This adds roughly a +/-8.5 minutes
>> skew to the current time.
>
> When the server tells the client that it supports the 0-RTT handshake
> scheme, can't the server also tell the client what time the server
> things it is? Then the client could calculate the offset between its
> local perception of the time and the server's perception of the time,
> and apply that offset to whatever timestamp it sends in its 0-RTT
> handshake.

I think this solution may also work. It is in fact that first solution
I considered. After I came up with the simpler random clock skew idea,
I stopped pursuing this further.

> Also, timestamps is only needed for the 0-RTT handshake, handshakes
> that aren't attempting to be 0-RTT shouldn't include a timestamp. So,
> the timestamps should probably be moved to the extension that
> negotiates the 0-RTT handshake. That way, the fingerprinting risk,
> whatever it is, is limited to applications that are actually trying to
> use that feature, and applications/servers that are especially
> sensitive to fingerprinting (e.g. the Tor Browser) may cleanly avoid
> the issue by disabling 0-RTT handshake support, as a worst-case
> option.

This is a good idea. However, this idea needs a little more work
because the timestamp must be part of the nonce input to the key
derivation function (the TLS PRF) in this anti-replay mechanism. So
the key derivation process for 0-RTT handshakes needs to also take the
timestamp in the 0-RTT handshake extension as input.

Wan-Teh Chang

From brian@briansmith.org  Fri Dec  6 14:22:36 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282131AE15A for ; Fri,  6 Dec 2013 14:22:36 -0800 (PST)
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 9auPBKhJR9jv for ; Fri,  6 Dec 2013 14:22:34 -0800 (PST)
Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB801AE146 for ; Fri,  6 Dec 2013 14:22:33 -0800 (PST)
Received: by mail-qe0-f49.google.com with SMTP id w7so1026751qeb.22 for ; Fri, 06 Dec 2013 14:22:30 -0800 (PST)
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=bd18v8sRlm2VSbz9Gq5OYPOJbfnWs0Zs5WazX11h+1A=; b=FAdNFplWgJKHdgqiktU9tOEAprIZ7OoS1OjS7NE6dNCpDi1XVyOfwXp5AW8ut5CFSz SieSBfFY+8UhsbGw0qHHoArOar56WtW15qXX16A1+moXPaIPlw/r7lDidozjL7gAG85g pWCEJ342E6zxCvJ/Z85I7aenf/jNMg71Sl/YapMzrrZdXjkdRskaLfA4w73Y2MloGw6j rAk0Hcv2ZmqlFDJZnudJDw5bjnjVdesk7DG3Wga40ja1qqIoMN9rqDYQosRZVJ/eFj5+ zbgR2y69fP/C7EQtGCwrgGko4mgFMKGmjaSEoC5Rw9fRlRHfsEF/9v8I6H8bPP7IFsEC XV+Q==
X-Gm-Message-State: ALoCoQnIM3KUGn4cxmVA2h/aYw4D+hKOS4aBY8H1se0PPb34jLRhAtN5gMz9a+wwiZ+ssJqaVgzj
MIME-Version: 1.0
X-Received: by 10.224.47.73 with SMTP id m9mr10813570qaf.23.1386368549979; Fri, 06 Dec 2013 14:22:29 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Fri, 6 Dec 2013 14:22:29 -0800 (PST)
X-Originating-IP: [63.245.219.53]
In-Reply-To: 
References:   
Date: Fri, 6 Dec 2013 14:22:29 -0800
Message-ID: 
From: Brian Smith 
To: Adam Langley 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 22:22:36 -0000

On Wed, Nov 27, 2013 at 7:28 AM, Adam Langley  wrote:
> On Tue, Nov 26, 2013 at 8:42 PM, Brian Smith  wrote:
>> these fallback connections add a lot of
>> latency. If we attempt a fallback connection in response to a
>> connection reset, and we receive an inappropriate_fallback alert, then
>> we'd have to make yet *another* connection without the fallback.
>
> I didn't have that in mind. In the code as I currently have it
> written, an inappropriate_fallback doesn't trigger an "upgrade".
> Rather the original error code that triggered the downgrade is
> remembered and returned.
>
> So the connection might go: TLS 1.2, connection reset; fallback to TLS
> 1.1, inappropriate_fallback; fail the connection with a connection
> reset error.
>
> We don't retry HTTP connections, after all.

Sorry for the delay.

Firefox does retry for connection resets. In fact, our TLS intolerance
mechanism is implemented by converting the error that causes us to
suspect TLS intolerance into a connection reset error code, and then
returning that connection reset error to our HTTP stack. In the case
of a RST in the middle of a GET request when pipelining is enabled,
Firefox will even resend the GET request on the assumption that it is
idempotent. Firefox has done things this way for a very long time,
presumably to help users get the results they want when they are on
flaky networks.

Anyway, it seems bad get a positive "yes, you can reach me and I will
respond" response from the server and then stop trying to communicate
with it. It is better to find some way to get the HTTP response that
the user is waiting for, if we can find one.

This is why I think it is better to try backporting TLS-1.2-only
cipher suites to TLS 1.1 and TLS 1.0, and then have clients send all
the same extensions in TLS 1.0 and TLS 1.1 that they would send in TLS
1.2, plus an indication of the max version supported in an extension
or an SCSV, and then let the server "upgrade" the connection to TLS
1.2 by using TLS 1.2 features while still indicating in its
ServerHello.server_version.

Granted, there is significant compatibility risk in doing this,
because some intermediary may choke somehow.  It will require
widespread experimentation to see how well it works. I am happy to
change Firefox to support this experiment if we can find partners
running servers on the internet that are also willing to experiment
with it.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

From skyper@thc.org  Fri Dec  6 14:31:07 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133261AD9AE for ; Fri,  6 Dec 2013 14:31:07 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 75XSMfdqPp6n for ; Fri,  6 Dec 2013 14:31:04 -0800 (PST)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 655021ADF81 for ; Fri,  6 Dec 2013 14:31:04 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id at1so2440313iec.33 for ; Fri, 06 Dec 2013 14:31:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O26pgMPgwZqj68oDW1Lrzw4CPSVW4T/hWmTiAniokvo=; b=UMYV/ZD1exvB0Rvr7HPWuISUBX4PS127elU/nhaJYwtdPfOl6KJXIux237HxmPPYdF hyOPBPYChOnLB6hzvtE6QPcBpixjkq0t+wPrgSFhq3bfS6yiG+H6LXdT6UPExfPJ4x33 0DPDwJlYbHMdjbE4xizCdivtkdguh2n/xV/Nk=
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=O26pgMPgwZqj68oDW1Lrzw4CPSVW4T/hWmTiAniokvo=; b=CkAHc2eKPxsGbjiMRI0ShA2XxAoKoFOrtdyUCk0rNJgFwD/3dz8fnb3IpA1y8XUaUC k9qd/5m+TuwvSZ9QuxtRxK/dC5mTPn95ZG6maT9c/uRHYjUw8pri4h198rrj8XEULwlC 7p+2cUmj8eCvPXPoplBryS67y9toZEy8DbJ7z9F3IJypfBzyAiVEEtd5NSFNh3TDmY8z Z52l5k0pSht6B1La4rqam5pt6AQzc+THPRKVj8PnEexk0A+85hJ6bvSry233OdabTT7u 9l6QoAVj5d7PnbeTzbuEd9TfrHjdg5QXShGDqDbbhJ35KlrWKK8EFAzZSoH3h8y8KMm9 UBkw==
X-Gm-Message-State: ALoCoQmifT4Ce5ZcXuiNJT/rHdcJgvVdjapY+LBtdI468UK99FO7h+lU4K+6Kopuxpp0gYBd9Tdt
MIME-Version: 1.0
X-Received: by 10.50.17.9 with SMTP id k9mr4910240igd.3.1386369060450; Fri, 06 Dec 2013 14:31:00 -0800 (PST)
Received: by 10.64.9.41 with HTTP; Fri, 6 Dec 2013 14:31:00 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: 
References:  
Date: Fri, 6 Dec 2013 22:31:00 +0000
Message-ID: 
From: Ralf Skyper Kaiser 
To: Brian Smith 
Content-Type: multipart/alternative; boundary=089e01182a3460eb8304ece533f4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 22:31:07 -0000

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

Hi,

the draft only concerns HTTPS (no other client side implementation attempts
a reconnect when it receives
a RST on  TLS 1.x [which is bad to start with but apparently necessary]).

A solution that solves some of the mentioned problems without any protocol
change is
to pin the TLS version the same way as certificates are pinned. And while
pinning the TLS
version it should also be considered to pin the cipher suite ("Use this
cipher suite or
a better one").

After first connect the client will not allow any lesser security (TLS 1.3,
ECDHE, ..) than the one
used on last connect.

regards,

ralf


On Wed, Nov 27, 2013 at 1:42 AM, Brian Smith  wrote:

> On Mon, Nov 25, 2013 at 3:27 PM, Adam Langley  wrote:
> >   In the event that a client is making a fallback connection, it
> > includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
> > current server which sees this cipher suite in a ClientHello SHOULD
> > return a fatal alert, inappropriate_fallback (86) and abort the
> > connection.
>
> Adam, I think what you propose makes sense. However, I think it might
> not be ideal if there are any circumstances where the browser could
> accidentally fall back to a lower version--e.g. falling back after a
> timeout or falling back in response to the connection being reset.
> AFAICT, we currently have to do fallback from TLS 1.2 -> TLS 1.1 and
> from TLS 1.1 -> TLS 1.0 in response to connection resets. There will
> be some false positives here. In addition to potentially reducing the
> security of the connection, these fallback connections add a lot of
> latency. If we attempt a fallback connection in response to a
> connection reset, and we receive an inappropriate_fallback alert, then
> we'd have to make yet *another* connection without the fallback. All
> other things being equal, it would be better if the server could
> respond respond exactly as it would with a TLS 1.2 ClientHello,
> without downgrading the cipher suite or any other feature, more like
> what Martin Rex suggested.
>
> However, I don't think it is realistic to backport features all the
> way to SSL 3.0. The information in the TLS extensions is too
> important, and trying to define good defaults for missing extensions
> that make sense long-term seems like it will just bind our hands too
> much in the future.
>
> So, we should could consider backporting TLS 1.2 cipher suites to TLS
> 1.1 and TLS 1.0, but then using your suggested inappropriate_fallback
> for for SSL 3.0 handshakes only.
>
> Whether this complication is justified depends on how frequently we
> receive false-positive connection resets (and anything else that can
> be a false positive) and how much we care about optimizing performance
> for that case.
>
> Cheers,
> Brian
> --
> Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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


Hi,

the draft only concerns HTTPS (n=
o other client side implementation attempts a reconnect when it receives
a RST on=A0 TLS 1.x [which is bad to start with but apparently neces=
sary]).


A solution that solves some of the mentioned problems without any=
 protocol change is
to pin the TLS version the same way as certificates =
are pinned. And while pinning the TLS
version it should also be consider=
ed to pin the cipher suite ("Use this cipher suite or

a better one").

After first connect the client will =
not allow any lesser security (TLS 1.3, ECDHE, ..) than the one
used on last connect.

regards,

ralf




On Wed, Nov 27, 2013 at 1:42 AM, Brian Smith <brian@briansmith.org> wrote:


On Mon, Nov 25, 2013 at 3:=
27 PM, Adam Langley <agl@google.com> wrote:



> =A0 In the event that a client is making a fal=
lback connection, it

> includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
> current server which sees this cipher suite in a ClientHello SHOULD
> return a fatal alert, inappropriate_fallback (86) and abort the

> connection.




Adam, I think what you propose makes sense. However, I think it might=


not be ideal if there are any circumstances where the browser could

accidentally fall back to a lower version--e.g. falling back after a

timeout or falling back in response to the connection being reset.

AFAICT, we currently have to do fallback from TLS 1.2 -> TLS 1.1 and

from TLS 1.1 -> TLS 1.0 in response to connection resets. There will

be some false positives here. In addition to potentially reducing the

security of the connection, these fallback connections add a lot of

latency. If we attempt a fallback connection in response to a

connection reset, and we receive an inappropriate_fallback alert, then

we'd have to make yet *another* connection without the fallback. All
other things being equal, it would be better if the server could

respond respond exactly as it would with a TLS 1.2 ClientHello,

without downgrading the cipher suite or any other feature, more like

what Martin Rex suggested.



However, I don't think it is realistic to backport features all the

way to SSL 3.0. The information in the TLS extensions is too

important, and trying to define good defaults for missing extensions

that make sense long-term seems like it will just bind our hands too

much in the future.



So, we should could consider backporting TLS 1.2 cipher suites to TLS

1.1 and TLS 1.0, but then using your suggested inappropriate_fallback

for for SSL 3.0 handshakes only.



Whether this complication is justified depends on how frequently we

receive false-positive connection resets (and anything else that can

be a false positive) and how much we care about optimizing performance

for that case.



Cheers,

Brian

--

Mozilla Networking/Crypto/Security (Necko/NSS/PSM)


_____________________=
__________________________

TLS mailing list

TLS@ietf.org

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





--089e01182a3460eb8304ece533f4--

From jpixton@gmail.com  Fri Dec  6 15:25:53 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6E21ADF63 for ; Fri,  6 Dec 2013 15:25:53 -0800 (PST)
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 7o6lHFsLGGZ2 for ; Fri,  6 Dec 2013 15:25:49 -0800 (PST)
Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DB9E21ADE87 for ; Fri,  6 Dec 2013 15:25:48 -0800 (PST)
Received: by mail-qe0-f44.google.com with SMTP id nd7so1090990qeb.3 for ; Fri, 06 Dec 2013 15:25:44 -0800 (PST)
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=poPAyj2TGJYLxpDTNPid5BT0d7tm+YM6MZXkzrMjXxM=; b=gV4X/pP8/J0X5DqZksudoVKZZAKLy0SrohgMPZTtzeW7uiCXk28Kk0R5iR+v6h4s6/ vzrECwCq3feQUWxWBOXR8ltYnX6nhJzN0RBAXrEPPRuKA5KZnNVZEDi0qe0kx/f8ConE SEhgPQRVJ59xolaFt7UclNP1sINCjzea9dU1DOJV7uhyKKBgoOvu+xDtHTsgc9W2JKBM /by/I2LBnFVc8oZ3Ldnq+8mNgJS5bUWhamS0wCeLgtB6lPorshY/dWUWzkG890uY5MM/ qT5QbP2VOmjOpK67shFpC7AOmJ0iyoMABa82t/9tRYa+2K+DDWIyeOinm/igPTHiVlfJ PdhA==
MIME-Version: 1.0
X-Received: by 10.224.47.3 with SMTP id l3mr11181825qaf.25.1386372344811; Fri, 06 Dec 2013 15:25:44 -0800 (PST)
Received: by 10.224.172.130 with HTTP; Fri, 6 Dec 2013 15:25:44 -0800 (PST)
Date: Fri, 6 Dec 2013 23:25:44 +0000
Message-ID: 
From: Joseph Birr-Pixton 
To: tls@ietf.org, dharkins@lounge.org
Content-Type: text/plain; charset=UTF-8
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 23:25:53 -0000

On 6 December 2013 20:00,   wrote:
> From: "Dan Harkins" 
> To: "CodesInChaos" 
> Cc: "tls@ietf.org" 
> Date: Fri, 6 Dec 2013 10:29:22 -0800 (PST)
> Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
>
> On Fri, December 6, 2013 3:14 am, CodesInChaos wrote:
>> Database compromises happen all the time, and forcing the server to
>> store a weakly hashed password
>> isn't acceptable IMO.
>
>   You're absolutely right, that would not be acceptable.
>
>   TLS-pwd uses HMAC-SHA256 with a 32 byte random key (salt) to
> hash passwords that the server stores.

How does this not constitute an immensely fast password oracle?

If the server stores (username, base, salt) per user with base :=
HMAC-SHA256(salt, username || password) you'd only need to compute
about 3 SHA256 blocks to check each candidate password.

Cheers,
Joe

From dharkins@lounge.org  Fri Dec  6 15:39:00 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB871AE13B for ; Fri,  6 Dec 2013 15:39:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 0khfrzGEOlGD for ; Fri,  6 Dec 2013 15:38:59 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED7A1AE0EA for ; Fri,  6 Dec 2013 15:38:59 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 581DC1022404C; Fri,  6 Dec 2013 15:38:55 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 6 Dec 2013 15:38:55 -0800 (PST)
Message-ID: <6f16d6d556c68a58918423e0419d31eb.squirrel@www.trepanning.net>
In-Reply-To: 
References: 
Date: Fri, 6 Dec 2013 15:38:55 -0800 (PST)
From: "Dan Harkins" 
To: "Joseph Birr-Pixton" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 06 Dec 2013 23:39:00 -0000

On Fri, December 6, 2013 3:25 pm, Joseph Birr-Pixton wrote:
> On 6 December 2013 20:00,   wrote:
>> From: "Dan Harkins" 
>> To: "CodesInChaos" 
>> Cc: "tls@ietf.org" 
>> Date: Fri, 6 Dec 2013 10:29:22 -0800 (PST)
>> Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
>>
>> On Fri, December 6, 2013 3:14 am, CodesInChaos wrote:
>>> Database compromises happen all the time, and forcing the server to
>>> store a weakly hashed password
>>> isn't acceptable IMO.
>>
>>   You're absolutely right, that would not be acceptable.
>>
>>   TLS-pwd uses HMAC-SHA256 with a 32 byte random key (salt) to
>> hash passwords that the server stores.
>
> How does this not constitute an immensely fast password oracle?
>
> If the server stores (username, base, salt) per user with base :=
> HMAC-SHA256(salt, username || password) you'd only need to compute
> about 3 SHA256 blocks to check each candidate password.

  It's a balanced PAKE protocol. Like all such schemes (e.g EKE, J-PAKE)
the database of passwords is presumed to not be available to the
attacker.

  Dan.




From sneves@dei.uc.pt  Fri Dec  6 18:28:13 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0114A1AE12A for ; Fri,  6 Dec 2013 18:28:13 -0800 (PST)
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, RP_MATCHES_RCVD=-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 8Qh69sAw8-Z4 for ; Fri,  6 Dec 2013 18:28:10 -0800 (PST)
Received: from smtp.dei.uc.pt (smtp.dei.uc.pt [193.137.203.253]) by ietfa.amsl.com (Postfix) with ESMTP id E03401AE0F6 for ; Fri,  6 Dec 2013 18:28:09 -0800 (PST)
Received: from [192.168.1.64] ([188.251.178.92]) (authenticated bits=0) by smtp.dei.uc.pt (8.14.4/8.14.4) with ESMTP id rB72ReoC032207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Dec 2013 02:27:46 GMT
Message-ID: <52A287A1.1030501@dei.uc.pt>
Date: Sat, 07 Dec 2013 02:27:45 +0000
From: Samuel Neves 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Robert Ransom , Nick Mathewson 
References:  <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com> <5296C6D7.2040509@dei.uc.pt> <1386332388.3430.22.camel@dhcp-2-127.brq.redhat.com>  <1386336151.3430.34.camel@dhcp-2-127.brq.redhat.com>  
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information
X-FCTUC-DEI-SIC-MailScanner-ID: rB72ReoC032207
X-FCTUC-DEI-SIC-MailScanner: Found to be clean
X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-60.25, required 3.252, autolearn=not spam, ALL_TRUSTED -10.00, BAYES_00 -0.25, L_SMTP_AUTH -50.00)
X-FCTUC-DEI-SIC-MailScanner-From: sneves@dei.uc.pt
Cc: "tls@ietf.org" 
Subject: Re: [TLS] chacha to replace RC4 (was: Salsa vs. ChaCha)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 02:28:13 -0000

On 06-12-2013 16:42, Robert Ransom wrote:
> On 12/6/13, Nick Mathewson  wrote:
>
>
>> That said, it's pretty trivial to adopt _any_ of the implementations
>> I've seen so that they would run incrementally; it's not a difficult
>> programming problem.  You'd need to add 512 bits of memory overhead
>> for each chacha instance, and you'd take a little performance overhead
>> from the bookkeeping, but that's not a huge deal.
> To get the performance that people expect from these stream ciphers,
> one would need to buffer (at least) three or four blocks, since the
> fastest implementations (Ted Krovetz's) generate three or more blocks
> in parallel.

It's unclear to me what the objection here is precisely, if there is one
at all. RC4 also works by XORing keystream into data. It just so happens
to output 1 byte per call, instead of 64. I agree with Nick that
changing existing implementations to be incremental is simple, and some
good ones already exist [1].

Let's not forget that the internal state of RC4 is 258 *bytes*. Chacha
has an internal state of 48 bytes (32 + 8 + 8), which leaves plenty of
space for an additional buffer of 128 or 256 keystream bytes (2 or 4
output blocks) without going overboard compared to RC4.

Additionally, the best RC4 implementations on current x86 processors
don't seem to do better than 4 cycles per byte; even mediocre Chacha or
Salsa20 implementations are going to be a performance upgrade, and the
best-case scenario will approach 1 cycle per byte.

[1] https://github.com/floodyberry/chacha-opt


From brian@briansmith.org  Fri Dec  6 19:44:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0411AE1D0 for ; Fri,  6 Dec 2013 19:44:35 -0800 (PST)
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 y-gyXANKbbbF for ; Fri,  6 Dec 2013 19:44:34 -0800 (PST)
Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBFE1AE017 for ; Fri,  6 Dec 2013 19:44:34 -0800 (PST)
Received: by mail-qc0-f182.google.com with SMTP id e16so1112453qcx.41 for ; Fri, 06 Dec 2013 19:44:30 -0800 (PST)
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=bmDPRzfR0h7/q5WFblgTMzgqANtiom2XETqQ2M1h8aI=; b=KtvIU6hBe1sv9elNIApcVvXrF7Jx8+MPOhDLqxiL7XQs27I6H9wsr3aRv1e4nZZgYX 6KcqBI12mV+9wwbwW+6VrX1rYOSSpijNSnpfqcQJna7FH4Od5tJX4fVlueAhXLEiPOYA h6euzp+aVsE2v2xws2ZB+Q1VykriL8kypGmg6vOs2zN0TBEftNX09+fsHTz4pyhY3i6d XlSXoV0So4B5FbzaKz6KlGx4u6+jdcaFWMlskRzqsKI1VvSK7A+6KC8dFipnTjkY4BJ6 cDJTh2UDaZha5KoWGjETuRYjuHKYRbSiPSFHKKyjBS27S5iA+qipNrBTv6fv4/UU+vBV nmDw==
X-Gm-Message-State: ALoCoQmTIzLQFSF74jOeWXDr6azWAPb+d6hhAEFntjq/5S652XMiBxShPNJ/9V+8OxC5JvipCW+K
MIME-Version: 1.0
X-Received: by 10.224.171.196 with SMTP id i4mr12617961qaz.38.1386387870429; Fri, 06 Dec 2013 19:44:30 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Fri, 6 Dec 2013 19:44:30 -0800 (PST)
X-Originating-IP: [63.245.219.53]
In-Reply-To: <1386335697.3430.31.camel@dhcp-2-127.brq.redhat.com>
References:  <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com> <5296C6D7.2040509@dei.uc.pt> <1386332388.3430.22.camel@dhcp-2-127.brq.redhat.com>  <1386335697.3430.31.camel@dhcp-2-127.brq.redhat.com>
Date: Fri, 6 Dec 2013 19:44:30 -0800
Message-ID: 
From: Brian Smith 
To: Nikos Mavrogiannopoulos 
Content-Type: text/plain; charset=UTF-8
Cc: "" 
Subject: Re: [TLS] chacha to replace RC4 (was: Salsa vs. ChaCha)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 03:44:35 -0000

On Fri, Dec 6, 2013 at 5:14 AM, Nikos Mavrogiannopoulos  wrote:
> Adam's draft proposes a novel scheme. While that this is a good scheme,
> it can only be used in TLS 1.2 or later, and there will be competing
> AEAD schemes coming from the CAESAR competition. We need a
> replacement for RC4 now, that can (ideally) be patched in old
> implementations as well.

AFAICT, there's no technical reason to prohibit AEAD in TLS 1.0 or TLS 1.1.

Also, I don't think TLS 1.2 is that much code to add to a TLS 1.0 or
TLS 1.1 implementation, especially if you're not supporting any new
cipher suites except the new ChaCha20 ones, and if you're not trying
to support any functionality above what what TLS 1.0 and TLS 1.1
provide.

Consequently, I don't think we should consider the AEAD construction
to be too much of a burden for anybody to implement in order to
support new cipher suites.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

From mrex@sap.com  Fri Dec  6 20:22:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83401AE1BF for ; Fri,  6 Dec 2013 20:22:41 -0800 (PST)
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 x65TZTc50six for ; Fri,  6 Dec 2013 20:22:39 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D90251AE00D for ; Fri,  6 Dec 2013 20:22:38 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rB74MW0S025196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Dec 2013 05:22:32 +0100 (MET)
In-Reply-To: <52A21B4B.2000301@fifthhorseman.net>
To: Daniel Kahn Gillmor 
Date: Sat, 7 Dec 2013 05:22:32 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20131207042232.3498C1AB40@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: IETF TLS WG 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
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: Sat, 07 Dec 2013 04:22:41 -0000

Daniel Kahn Gillmor wrote:
> On 12/06/2013 01:25 PM, Martin Rex wrote:
>>
>> So the use of the TLS_FALLBACK_SCSV will either *NOT* affect the rest
>> of the TLS protocol not at all, or cause a fatal handshake failure.
>> And very few, if any at all, of the situations where the handshake fails,
>> will be instances of an active attack.
> 
> This is probably also true of X.509 certificate validation failure as
> well, since there are more self-signed or expired certificates in active
> use than there are active MITM attackers.  Are you suggesting that TLS
> would be better off not checking certificate validity?

When both peers manage to signal to each other that they could
have done better, why moaning, failing and annoying the user,
when those peers could simply *USE* those better features instead.


> 
> > And it remains extremely
> > questionable, when the handshake would succeed, that the attacker
> > will gain anything at all.
> 
> What the attacker can gain presumably depends on what features the
> client is willing to sacrifice during fallback.  Presumably, the client
> gives up specific features of the newer versions: e.g. AEAD, when
> falling back below TLS 1.2, or possibly all TLS extensions for fallback
> all the way to SSLv3 (to accomodate old extension-intolerant SSLv3 servers).
> 
> It looks like you're saying that none of these more modern features are
> useful tools in defending against an active attacker.  Do you really
> think that?


I really think that trying to reduce the large scale of grey into
a binary black/white guess by the server about what the client
_might_ deem appropriate is doomed to fail.

If the client wants to make a conscious security trade-off decision
about what features it is willing to sacrifice to obtain interoperability,
then it is the _client_ which should perform the decision.  And in case
of a client operated by a human user (such as a web browser), that
trade-off might involve asking the user.

The server doesn't know anything about the client's motivation,
nothing about the actual request that the client is intending to
submit and nothing about the trade-off that the client would
be willing to perform (rather than fail).


Btw. AES128-CBC-SHA1 is more secure than AES128-GCM/-CCM, so the only
thing the client might be "loosing" is a little performance, and
that AEAD can not currently be negotiated and used unless
ClientHello.client_version is set to { 0x03, 0x03 } is a silly defect
of the specification(s) that could be easily fixed.

Btw. am I reading this page correctly:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757%28v=vs.85%29.aspx

Does Microsoft limit AES-GCM really to ECDHE_ECDSA on Win7 and Win8
i.e. unavailable with ECDHE_RSA ?


-Martin

From mrex@sap.com  Fri Dec  6 20:38:54 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B061AE1EB for ; Fri,  6 Dec 2013 20:38:54 -0800 (PST)
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 6sL6XnkLnmZ3 for ; Fri,  6 Dec 2013 20:38:52 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 27CAB1AE027 for ; Fri,  6 Dec 2013 20:38:52 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rB74chOi029134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Dec 2013 05:38:43 +0100 (MET)
In-Reply-To: 
To: Adam Langley 
Date: Sat, 7 Dec 2013 05:38:43 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20131207043843.9D7D81AB40@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
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: Sat, 07 Dec 2013 04:38:54 -0000

Adam Langley wrote:
> Martin Rex  wrote:
>>
>> For this feature to work at all, the prerequisite is that both communication
>> peers must be updated.  When looking at a protocol feature that requires
>> both communication peers to be updated as a prerequisite, wouldn't it be
>> preferable to fix those protocol features of SSL/TLS that we deem necessary
>> for reliable security to become negotiable even in the "most conservative"
>> ClientHello that clients are willing to fallback to?
> 
> Fallback behaviour is needed for wide variety of buggy servers,
> including those that are intolerant to unknown extensions.
> 
> I don't believe that there's a ClientHello format that is both devoid
> of compat issues and sufficiently expressive to be able to negotiate
> what we need now and in the future.


If you *NEED* a certain feature, then there would not be a point in
a reconnect fallback to a ClientHello that doesn't have that feature.
So you would not need an SCSV to cover this, methinks.

-Martin

From watsonbladd@gmail.com  Fri Dec  6 22:32:58 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BE31AE244 for ; Fri,  6 Dec 2013 22:32:58 -0800 (PST)
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 8B88mLzxps-l for ; Fri,  6 Dec 2013 22:32:57 -0800 (PST)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 59C3F1ADF23 for ; Fri,  6 Dec 2013 22:32:57 -0800 (PST)
Received: by mail-we0-f180.google.com with SMTP id t61so1525421wes.39 for ; Fri, 06 Dec 2013 22:32:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t84pCZlHffACG6WPBMHNKD2M4QINmv2KmoXvhVFJsXU=; b=FXx6sS53qCFW3HdFFLF2NfZ3QvXnUIfY5BVeTJJL4KoVvWciTD9CSdHw9gmR9PhgD+ stqJb0IMTFgm3rSmzuevXmk4EIpWmrt/8H+066gImcDsdMGd4iblkZ3JUFbeVc6A1CtV z+ylKCmyL6NL4xTyh2t9oQGM8ZozLpKhHHtaSaQvJFEgua8OZcyTV5U5Hf0krHN//Iuq +56zmPhcZbeXa2V08uLoGIyBtk2diUoFAgNx1arWNtHjOVbYoPb0I5+FwE+poOTJkxqu UCComYJQ+AV0BacKrSYEDuD1L437vA+CT6J5Wraj1YoIv3tDrifXr1YHnvl8yAuKi7jQ 3T6g==
MIME-Version: 1.0
X-Received: by 10.194.48.115 with SMTP id k19mr25990802wjn.47.1386397972829; Fri, 06 Dec 2013 22:32:52 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Fri, 6 Dec 2013 22:32:52 -0800 (PST)
In-Reply-To: <20131207042232.3498C1AB40@ld9781.wdf.sap.corp>
References: <52A21B4B.2000301@fifthhorseman.net> <20131207042232.3498C1AB40@ld9781.wdf.sap.corp>
Date: Fri, 6 Dec 2013 22:32:52 -0800
Message-ID: 
From: Watson Ladd 
To: mrex@sap.com
Content-Type: text/plain; charset=UTF-8
Cc: IETF TLS WG 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 06:32:59 -0000

To clarify.
>
> Btw. AES128-CBC-SHA1 is more secure than AES128-GCM/-CCM, so the only
> thing the client might be "loosing" is a little performance, and
> that AEAD can not currently be negotiated and used unless
> ClientHello.client_version is set to { 0x03, 0x03 } is a silly defect
> of the specification(s) that could be easily fixed.
I am assuming you are discussing the modes as specified and
implemented in TLS? In that case you are dead wrong.
Lucky 13, BEAST, and even if we drop all that no protocol depending
both on SHA1 and AES can be stronger than one depending
on AES alone.
Sincerely,
Watson Ladd

From mrex@sap.com  Fri Dec  6 22:43:02 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902621AE264 for ; Fri,  6 Dec 2013 22:43:02 -0800 (PST)
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 s9WLHRzKbnSd for ; Fri,  6 Dec 2013 22:43:01 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 06CD81AE243 for ; Fri,  6 Dec 2013 22:43:00 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rB76gsgE004765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Dec 2013 07:42:54 +0100 (MET)
In-Reply-To: 
To: Watson Ladd 
Date: Sat, 7 Dec 2013 07:42:54 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20131207064254.4B0551AB3B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: IETF TLS WG 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
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: Sat, 07 Dec 2013 06:43:02 -0000

Watson Ladd wrote:
[ Charset UTF-8 unsupported, converting... ]
> To clarify.
> >
> > Btw. AES128-CBC-SHA1 is more secure than AES128-GCM/-CCM, so the only
> > thing the client might be "loosing" is a little performance, and
> > that AEAD can not currently be negotiated and used unless
> > ClientHello.client_version is set to { 0x03, 0x03 } is a silly defect
> > of the specification(s) that could be easily fixed.
>
> I am assuming you are discussing the modes as specified and
> implemented in TLS? In that case you are dead wrong.
> Lucky 13, BEAST, and even if we drop all that no protocol depending
> both on SHA1 and AES can be stronger than one depending
> on AES alone.

Lucky 13 and BEAST are completely irrelevant for the majority
of usage scenarios, and there's even a simple 1/(n-1) record splitting
workaround for BEAST for those with paranoia.

I don't know what you mean by "AES alone", but if you are refering
to "AES-GCM", that isn't AES alone, but AES in combination with GHASH,
and HMAC-SHA1 beats the security of GHASH by a huge safety margin.

-Martin

From watsonbladd@gmail.com  Fri Dec  6 22:50:39 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07121AE286 for ; Fri,  6 Dec 2013 22:50:38 -0800 (PST)
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 2uUZBIoE-3ne for ; Fri,  6 Dec 2013 22:50:37 -0800 (PST)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 062991AE281 for ; Fri,  6 Dec 2013 22:50:36 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id z12so1512654wgg.3 for ; Fri, 06 Dec 2013 22:50:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VwqwQ2DTOcAWwBDBwi/PeURdQ0V+MB4E44NC11cKEKA=; b=vSEh6Z8F4+I/uC9BbA3eIcmPS07E7AYNfoo1u4E5JcKfUBqcRSxfVTKgEpzVSFbiaM pEyh6b2C1cTB4fpnbID0zuJyPgUfYF9QiaRMACjT+/rBvlRaEMH1u5XiRj0RJZNuuXz/ XueXqcLh4SFUFQeH3CC3N/gtovF4wPtf4B09SdCYIOOJxyY1LHHiBE6YToHDvNxMvsSb d2B0UMoKn4miSno4Ka6F/QjUKIJIYDIYRDSeRLXrmaVJKu21Y43GE2R2SwAb8BGGhJJV H+orlrKis+ojq9dNwZL6IUE5M0/tPenwswExDsnOya7ysXR0beIWpLm3D+tjFd1VhimL fIjQ==
MIME-Version: 1.0
X-Received: by 10.180.13.242 with SMTP id k18mr5743173wic.44.1386399032525; Fri, 06 Dec 2013 22:50:32 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Fri, 6 Dec 2013 22:50:32 -0800 (PST)
In-Reply-To: <20131207064254.4B0551AB3B@ld9781.wdf.sap.corp>
References:  <20131207064254.4B0551AB3B@ld9781.wdf.sap.corp>
Date: Fri, 6 Dec 2013 22:50:32 -0800
Message-ID: 
From: Watson Ladd 
To: mrex@sap.com
Content-Type: text/plain; charset=UTF-8
Cc: IETF TLS WG 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 06:50:39 -0000

On Fri, Dec 6, 2013 at 10:42 PM, Martin Rex  wrote:
> Watson Ladd wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> To clarify.
>> >
>> > Btw. AES128-CBC-SHA1 is more secure than AES128-GCM/-CCM, so the only
>> > thing the client might be "loosing" is a little performance, and
>> > that AEAD can not currently be negotiated and used unless
>> > ClientHello.client_version is set to { 0x03, 0x03 } is a silly defect
>> > of the specification(s) that could be easily fixed.
>>
>> I am assuming you are discussing the modes as specified and
>> implemented in TLS? In that case you are dead wrong.
>> Lucky 13, BEAST, and even if we drop all that no protocol depending
>> both on SHA1 and AES can be stronger than one depending
>> on AES alone.
>
> Lucky 13 and BEAST are completely irrelevant for the majority
> of usage scenarios, and there's even a simple 1/(n-1) record splitting
> workaround for BEAST for those with paranoia.
Paranoia is a requirement for this WG.
>
> I don't know what you mean by "AES alone", but if you are refering
> to "AES-GCM", that isn't AES alone, but AES in combination with GHASH,
> and HMAC-SHA1 beats the security of GHASH by a huge safety margin.
No, GHASH has an unconditional security guarantee, while HMAC is only
conjectured to be secure.
If you break AES-GCM you break AES, and hence AES-CBC-SHA1.
AES-CBC-SHA1 also falls if
HMAC fails.
>
> -Martin



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

From mrex@sap.com  Fri Dec  6 23:32:33 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930AF1AE245 for ; Fri,  6 Dec 2013 23:32:33 -0800 (PST)
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 UchwABe6zCD8 for ; Fri,  6 Dec 2013 23:32:31 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 81B571AE04A for ; Fri,  6 Dec 2013 23:32:31 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rB77WPFY007102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Dec 2013 08:32:25 +0100 (MET)
In-Reply-To: 
To: Watson Ladd 
Date: Sat, 7 Dec 2013 08:32:25 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20131207073225.0F79D1AB3B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: IETF TLS WG 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
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: Sat, 07 Dec 2013 07:32:33 -0000

Watson Ladd wrote:
> Martin Rex  wrote:
>>
>> Btw. AES128-CBC-SHA1 is more secure than AES128-GCM/-CCM, so the only
>> thing the client might be "loosing" is a little performance, and
>> that AEAD can not currently be negotiated and used unless
>> ClientHello.client_version is set to { 0x03, 0x03 } is a silly defect
>> of the specification(s) that could be easily fixed.
>>
>> I am assuming you are discussing the modes as specified and
>> implemented in TLS? In that case you are dead wrong.
>> Lucky 13, BEAST, and even if we drop all that no protocol depending
>> both on SHA1 and AES can be stronger than one depending
>> on AES alone.
>>
>> Lucky 13 and BEAST are completely irrelevant for the majority
>> of usage scenarios, and there's even a simple 1/(n-1) record splitting
>> workaround for BEAST for those with paranoia.
>
> Paranoia is a requirement for this WG.

TLSv1.1 and TLSv1.2 seem to have been developed without paranoia.

The attack surface provided by mac-pad-encrypt rather than the
obvious fix pad-mac-encrypt, which Lucky 13 exploited, was clearly
pointed out by Serge Vaudenay in 2001, but completely ignored by
the TLS WG in 2006 (TLSv1.1) and again in 2008 (TLSv1.2).

Replacing the (rsa,md5+sha1) digitally-signed from SSLv3->TLSv1.1 with
(rsa,sha1) or (rsa,md5) in TLSv1.2 is huge degradation in security,
certainly nothing that someone with paranoia would do. 


>
> > I don't know what you mean by "AES alone", but if you are refering
> > to "AES-GCM", that isn't AES alone, but AES in combination with GHASH,
> > and HMAC-SHA1 beats the security of GHASH by a huge safety margin.
>
> No, GHASH has an unconditional security guarantee, while HMAC is only
> conjectured to be secure.

If that were a real concern, then you would have to violently
oppose to Peter's (and other folks) suggestion to change
from mac-pad-encrypt to pad-encrypt-mac (aka EtA).

>
> If you break AES-GCM you break AES, and hence AES-CBC-SHA1.
> AES-CBC-SHA1 also falls if
> HMAC fails.

Currently HMAC-SHA1 in TLS is protected by AES CBC encryption,
so it is simply impossible to attack HMAC-SHA1 without first breaking AES.

In contrast to AES-GCM, you can not target and flip individual bits
of the MAC'ed plaintext from AES-CBC-SHA1 nor can you target and flip
individual bits from the HMAC-SHA1 output.  You actually do not not
anything about what goes in and what comes out of HMAC-SHA1 right now.


-Martin

From henry.story@bblfish.net  Sat Dec  7 02:16:08 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D501C1AE043 for ; Sat,  7 Dec 2013 02:16:08 -0800 (PST)
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,  J_CHICKENPOX_25=0.6, 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 udhX0SxUcN8J for ; Sat,  7 Dec 2013 02:16:07 -0800 (PST)
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id B91211AD72A for ; Sat,  7 Dec 2013 02:16:06 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id k14so1649901wgh.22 for ; Sat, 07 Dec 2013 02:16:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=KxZhhNnkMLS2ybsgwJNSJ0nNXnCAxeJcR2n+MCh/My4=; b=kvCnTxB/lQZOyBXIvcqsegvf9jfGB4zMFKQgnLi+gN+RGuMa2/NlNA79oiEw2VJQVX feDgp6uJqoaHHA4OymahkaK1pJyxFqo4aLWKR5Xe8lKnXY6Rkent+DOvs6tVpQE9uV9u vOkCcoNk09ld9RF5zvPf7/yGkTeOTJ/0npcHF8tS/ejMf9z0vutN9KFiJeGmiGNjhO8U u2Nhf4ficpJ72JIOEm7VtBxeglKwROAERPZZcIU+m0q0vk1Yzd2IjTaelAik0p2+wWpM cxzp0E3J2s3cqIyisE9NNFebl1Z13al3EZYdPtGgzlsnxwdx6MUSzx0whclNXE9cJrXW m+jQ==
X-Gm-Message-State: ALoCoQlmY9Km/aC3GfAhzP+VBxxi07MHEnYr4V2WxwLNCH5hIzrzPJw6P+c3tq97vhToZrbgGJo6
X-Received: by 10.180.101.41 with SMTP id fd9mr6404417wib.14.1386411362120; Sat, 07 Dec 2013 02:16:02 -0800 (PST)
Received: from bblfish.home (AAubervilliers-652-1-119-108.w83-200.abo.wanadoo.fr. [83.200.86.108]) by mx.google.com with ESMTPSA id nb16sm4184806wic.0.2013.12.07.02.15.59 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 02:15:59 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Henry Story 
In-Reply-To: <5239F4C9.5090805@pobox.com>
Date: Sat, 7 Dec 2013 11:15:56 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <01CA3CC6-C3C4-4412-80F8-E7101BA5C209@bblfish.net>
References: <5239F4C9.5090805@pobox.com>
To: Michael D'Errico 
X-Mailer: Apple Mail (2.1822)
Cc: TLS Mailing List , public-webid WebID Group 
Subject: Re: [TLS] TLS 1.3 wishlist
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 10:16:08 -0000

On 18 Sep 2013, at 20:45, Michael D'Errico  wrote:

> A "wish list" for an upcoming new version of TLS is available
> online (I found it via a message on Twitter):
> 
> https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf
> 
> Is it appropriate to discuss this now, prior to rechartering?

Hi,

  One thing that would be nice would be some way of having more flexibility
for the server to request a client certificate. In TLS 1.2 it seems
the only way to do this is to use the certificate_authorities
list. 

  With WebID over TLS [1] a server may in fact be satisfied if the 
Client certificate contains a WebID in the Subject Alternative Name.
But this then leaves the question open as to how the server can transmit
to the client it's ability to accept such certificates.

The only solution currently available that I know of 
would be to create a CA with DN such as

   CN=WebID, O={}

that every WebID enabled certificate would claim it is signed by (somewhere
in the certificte chain)

Then this could be passed by the server in the certificate_authorities
list as specified in http://tools.ietf.org/html/rfc5246#section-7.4.6


Some people are worried that this would require CAs to resign their root
CAs with a WebID certificate in case they wanted to release WebID 
certificates.

Is there a better way to do this currently? Could there be a better 
way to do it?


Henry


[1] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html


Social Web Architect
http://bblfish.net/


From yaronf.ietf@gmail.com  Sat Dec  7 02:40:58 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFE21AE2BE for ; Sat,  7 Dec 2013 02:40:58 -0800 (PST)
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 G1U8Oxg_ww6E for ; Sat,  7 Dec 2013 02:40:56 -0800 (PST)
Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD7E1AE2BC for ; Sat,  7 Dec 2013 02:40:56 -0800 (PST)
Received: by mail-ee0-f52.google.com with SMTP id d17so700450eek.39 for ; Sat, 07 Dec 2013 02:40:52 -0800 (PST)
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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VXCf4ddiZ/7BPOE2g4a3tIMbZYuWV8idP1e1s/9XhoE=; b=zG1dr2nuODqvNVcm1+ccHq5XRBoDzoybuJucKqYISB5rGWYyShd/p8cAr38WwJJRdi fSdvWONMHD2qYcVcInv5ePBL93shjq0bM8gOvbvyVJV2sCXJK4aUnfD/6llhftiPIG+3 hQyhI47APpXTFr+2C2MSjnuQT2oW15uXhZoPBMQDKY3X5x38gwlza28cjBNxpg7iVpuJ ecU59qYwlyqq0eteLc6c7Z0go3zCi5ifZvakXmfp0tksKywHQqcmCKrniUkKdiJwM9y7 t/ZR7cJmQuaILcR0JaIi3Cglzm87NOfydgQbiB+yzbvgeXdB4yM38jNlUeAaNxbZYVri WTow==
X-Received: by 10.14.109.5 with SMTP id r5mr41956eeg.110.1386412851974; Sat, 07 Dec 2013 02:40:51 -0800 (PST)
Received: from [10.0.0.2] ([109.65.142.155]) by mx.google.com with ESMTPSA id m1sm5173339eeg.0.2013.12.07.02.40.50 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 02:40:51 -0800 (PST)
Message-ID: <52A2FB32.30004@gmail.com>
Date: Sat, 07 Dec 2013 12:40:50 +0200
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: tls@ietf.org
References:   
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 10:40:58 -0000

Hi Ralf,

I like the idea of pinning the version number, but I don't think it will 
work well in clusters without significant tinkering (i.e., protocol 
changes): the client connects to cluster member A which has just 
upgraded to TLS 1.3 and immediately pins that server to 1.3. Now it 
connects to another cluster member which is still on TLS 1.2, and the 
connection is reset.

I don't understand how you could pin "ECDHE" - you would need to define 
whether DHE is better or worse than ECDHE, and I don't think we want to 
make that judgment call.

Thanks,
	Yaron

On 12/07/2013 12:31 AM, Ralf Skyper Kaiser wrote:
> Hi,
>
> the draft only concerns HTTPS (no other client side implementation
> attempts a reconnect when it receives
> a RST on  TLS 1.x [which is bad to start with but apparently necessary]).
>
> A solution that solves some of the mentioned problems without any
> protocol change is
> to pin the TLS version the same way as certificates are pinned. And
> while pinning the TLS
> version it should also be considered to pin the cipher suite ("Use this
> cipher suite or
> a better one").
>
> After first connect the client will not allow any lesser security (TLS
> 1.3, ECDHE, ..) than the one
> used on last connect.
>
> regards,
>
> ralf
>
>
> On Wed, Nov 27, 2013 at 1:42 AM, Brian Smith  > wrote:
>
>     On Mon, Nov 25, 2013 at 3:27 PM, Adam Langley      > wrote:
>      >   In the event that a client is making a fallback connection, it
>      > includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
>      > current server which sees this cipher suite in a ClientHello SHOULD
>      > return a fatal alert, inappropriate_fallback (86) and abort the
>      > connection.
>
>     Adam, I think what you propose makes sense. However, I think it might
>     not be ideal if there are any circumstances where the browser could
>     accidentally fall back to a lower version--e.g. falling back after a
>     timeout or falling back in response to the connection being reset.
>     AFAICT, we currently have to do fallback from TLS 1.2 -> TLS 1.1 and
>     from TLS 1.1 -> TLS 1.0 in response to connection resets. There will
>     be some false positives here. In addition to potentially reducing the
>     security of the connection, these fallback connections add a lot of
>     latency. If we attempt a fallback connection in response to a
>     connection reset, and we receive an inappropriate_fallback alert, then
>     we'd have to make yet *another* connection without the fallback. All
>     other things being equal, it would be better if the server could
>     respond respond exactly as it would with a TLS 1.2 ClientHello,
>     without downgrading the cipher suite or any other feature, more like
>     what Martin Rex suggested.
>
>     However, I don't think it is realistic to backport features all the
>     way to SSL 3.0. The information in the TLS extensions is too
>     important, and trying to define good defaults for missing extensions
>     that make sense long-term seems like it will just bind our hands too
>     much in the future.
>
>     So, we should could consider backporting TLS 1.2 cipher suites to TLS
>     1.1 and TLS 1.0, but then using your suggested inappropriate_fallback
>     for for SSL 3.0 handshakes only.
>
>     Whether this complication is justified depends on how frequently we
>     receive false-positive connection resets (and anything else that can
>     be a false positive) and how much we care about optimizing performance
>     for that case.
>
>     Cheers,
>     Brian
>     --
>     Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
>     _______________________________________________
>     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 anders.rundgren.net@gmail.com  Sat Dec  7 03:09:07 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D7A1AE2DC for ; Sat,  7 Dec 2013 03:09:07 -0800 (PST)
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_25=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 aYS5_rkDVjex for ; Sat,  7 Dec 2013 03:09:06 -0800 (PST)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E11171AE2CE for ; Sat,  7 Dec 2013 03:09:05 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id hq4so2006899wib.5 for ; Sat, 07 Dec 2013 03:09:01 -0800 (PST)
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=76YQDa11lpeupgm2pZ72yHx3tlmSlTiHrNXGC/IlQoY=; b=029dDLDsGcfukITOqYZjd1YXPgEJPFZDM59fLBjS2oqw6UcpH0ET+jAWAuNeneH95S dVZEoWsqMr1UOfb/Trp/itGHNerg9iNeproAB9N5AlvoZUu9TIzlabZSeizVp18/yo6q 67OosKEFGOJL9Y8aSG10v/KUKZDD544iEjY5Ts4PoTGpfCBanUniVc9dAfALXQdfVn/d UqwFxbd8/Q/GBDoBp8LR4djs4AKyh+EQTE8d/fwUBu/wYgH8wF0HGj5xhPofK+yvC2LX X78OJJPm+ZkDx5eUfhKUfggXMG2aTnyzAzGJpmyt0rLVLGeEPtDRr94iVEi1iiNozzpb b0Xg==
X-Received: by 10.180.73.70 with SMTP id j6mr6413070wiv.47.1386414541436; Sat, 07 Dec 2013 03:09:01 -0800 (PST)
Received: from [192.168.1.99] (33.50.125.78.rev.sfr.net. [78.125.50.33]) by mx.google.com with ESMTPSA id f11sm4534307wic.4.2013.12.07.03.09.00 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 03:09:01 -0800 (PST)
Message-ID: <52A301C5.50608@gmail.com>
Date: Sat, 07 Dec 2013 12:08:53 +0100
From: Anders Rundgren 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Henry Story ,  Michael D'Errico 
References: <5239F4C9.5090805@pobox.com> <01CA3CC6-C3C4-4412-80F8-E7101BA5C209@bblfish.net>
In-Reply-To: <01CA3CC6-C3C4-4412-80F8-E7101BA5C209@bblfish.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: TLS Mailing List 
Subject: Re: [TLS] TLS 1.3 wishlist
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 11:09:08 -0000

On 2013-12-07 11:15, Henry Story wrote:
> 
> On 18 Sep 2013, at 20:45, Michael D'Errico  wrote:
> 
>> A "wish list" for an upcoming new version of TLS is available
>> online (I found it via a message on Twitter):
>>
>> https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf
>>
>> Is it appropriate to discuss this now, prior to rechartering?
> 
> Hi,
> 
>   One thing that would be nice would be some way of having more flexibility
> for the server to request a client certificate. In TLS 1.2 it seems
> the only way to do this is to use the certificate_authorities
> list. 
> 
>   With WebID over TLS [1] a server may in fact be satisfied if the 
> Client certificate contains a WebID in the Subject Alternative Name.
> But this then leaves the question open as to how the server can transmit
> to the client it's ability to accept such certificates.
> 
> The only solution currently available that I know of 
> would be to create a CA with DN such as
> 
>    CN=WebID, O={}
> 
> that every WebID enabled certificate would claim it is signed by (somewhere
> in the certificte chain)
> 
> Then this could be passed by the server in the certificate_authorities
> list as specified in http://tools.ietf.org/html/rfc5246#section-7.4.6
> 
> 
> Some people are worried that this would require CAs to resign their root
> CAs with a WebID certificate in case they wanted to release WebID 
> certificates.
> 
> Is there a better way to do this currently? Could there be a better 
> way to do it?

I believe we had this discussion before, so here we go again :-)
Making TLS CCA (Client Certificate Authentication) useful for consumer authentication (be it to an enterprise, bank or social network), is IMO unrealistic, no matter how desirable it may be.

Technical reasons:
http://webpki.org/papers/PKI/webauth.pdf#page=1

TLS CCA is also at odds with the market:
http://www.forbes.com/sites/amadoudiallo/2013/11/30/google-wants-to-make-your-passwords-obsolete

As an authentication solution for VPNs (and even more "secure box-2-box" communication), TLS CCA is great but that's not "le web".

Regarding the specific WebID issue, I would be cautious about assigning additional semantics to existing constructs.
X.509 offers many other ways of signalling a unique/non-standard use.

Cheers,
Anders

> 
> 
> Henry
> 
> 
> [1] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html
> 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 


From henry.story@bblfish.net  Sat Dec  7 04:11:30 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B561AE2FD for ; Sat,  7 Dec 2013 04:11:30 -0800 (PST)
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,  J_CHICKENPOX_25=0.6, 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 slYzsXCJijCK for ; Sat,  7 Dec 2013 04:11:20 -0800 (PST)
Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9851ADBD3 for ; Sat,  7 Dec 2013 04:11:20 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id u56so1732216wes.36 for ; Sat, 07 Dec 2013 04:11:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=lOdyar9m5BuNuid1fY63WpuHk4MZifGncwbzAtwV2xA=; b=VxEcVpcBrJQISjT4j2yDOopPq+3lWdHbPCyW9HRasOTF5pvq2SnQpPBMz0Ht2Ul2C4 K9rVoFAXiROCLljLhvY0R6aKAgZk59ET3epHn76jcScdQP68u2H1d19NjMg4vmB3bL+e C61vGtWvxFcwY3Za6n/t2xj59k9Rt6yO5Qk+5k26cCFbjvjj6zB8FjE0/b9AooUEPogx Df2AFdCYhy1Ad0/hYvubyP3WFe/hl9z7dACmT9fXBmd+eREHK0EkG6JopNn3Oj6aKald 3+Hpe2lAAUlkdPAwOnDPLxUVNPyOnUoXd6+la2IxWdyIU7de68XrtJANQqpXAiGdScAb aJqg==
X-Gm-Message-State: ALoCoQn9FyvLsSCwand7X1Si/7qd101uWJhUMNycPOPrT2iFpNKrecIMxUzVExRjqN7KkiE8xDZB
X-Received: by 10.194.60.103 with SMTP id g7mr60317658wjr.37.1386418275694; Sat, 07 Dec 2013 04:11:15 -0800 (PST)
Received: from bblfish.home (AAubervilliers-652-1-119-108.w83-200.abo.wanadoo.fr. [83.200.86.108]) by mx.google.com with ESMTPSA id hv5sm4983964wib.2.2013.12.07.04.11.12 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 04:11:13 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Henry Story 
In-Reply-To: <52A301C5.50608@gmail.com>
Date: Sat, 7 Dec 2013 13:11:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5239F4C9.5090805@pobox.com> <01CA3CC6-C3C4-4412-80F8-E7101BA5C209@bblfish.net> <52A301C5.50608@gmail.com>
To: Anders Rundgren 
X-Mailer: Apple Mail (2.1822)
Cc: TLS Mailing List 
Subject: Re: [TLS] TLS 1.3 wishlist - better certificate selection
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 12:11:31 -0000

On 7 Dec 2013, at 12:08, Anders Rundgren  =
wrote:

> On 2013-12-07 11:15, Henry Story wrote:
>>=20
>> On 18 Sep 2013, at 20:45, Michael D'Errico  =
wrote:
>>=20
>>> A "wish list" for an upcoming new version of TLS is available
>>> online (I found it via a message on Twitter):
>>>=20
>>> https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf
>>>=20
>>> Is it appropriate to discuss this now, prior to rechartering?
>>=20
>> Hi,
>>=20
>>  One thing that would be nice would be some way of having more =
flexibility
>> for the server to request a client certificate. In TLS 1.2 it seems
>> the only way to do this is to use the certificate_authorities
>> list.=20
>>=20
>>  With WebID over TLS [1] a server may in fact be satisfied if the=20
>> Client certificate contains a WebID in the Subject Alternative Name.
>> But this then leaves the question open as to how the server can =
transmit
>> to the client it's ability to accept such certificates.
>>=20
>> The only solution currently available that I know of=20
>> would be to create a CA with DN such as
>>=20
>>   CN=3DWebID, O=3D{}
>>=20
>> that every WebID enabled certificate would claim it is signed by =
(somewhere
>> in the certificte chain)
>>=20
>> Then this could be passed by the server in the =
certificate_authorities
>> list as specified in http://tools.ietf.org/html/rfc5246#section-7.4.6
>>=20
>>=20
>> Some people are worried that this would require CAs to resign their =
root
>> CAs with a WebID certificate in case they wanted to release WebID=20
>> certificates.
>>=20
>> Is there a better way to do this currently? Could there be a better=20=

>> way to do it?
>=20
> I believe we had this discussion before, so here we go again :-)
> Making TLS CCA (Client Certificate Authentication) useful for consumer =
authentication (be it to an enterprise, bank or social network), is IMO =
unrealistic, no matter how desirable it may be.
>=20
> Technical reasons:
> http://webpki.org/papers/PKI/webauth.pdf#page=3D1

This thread is not about your ideas of what is wrong with TLS and
why you think it can never be solved, but what can be done to improve
one particular aspect that concerns me. =20

Btw. your article mixes up User Interface issues which can be sorted by=20=

browser vendors UI team with protocol issues which I want to discuss =
here.
( Eg: logging out would be easy if the browser showed the client =
certificate
used when logged in ). =20


>=20
> TLS CCA is also at odds with the market:
> =
http://www.forbes.com/sites/amadoudiallo/2013/11/30/google-wants-to-make-y=
our-passwords-obsolete
>=20
> As an authentication solution for VPNs (and even more "secure =
box-2-box" communication), TLS CCA is great but that's not "le web".

WebID allows you to use X509 Certs for global authentication without =
needing to=20
pass through CAs. We are using this every day and building some very =
cool apps on it.=20

>=20
> Regarding the specific WebID issue, I would be cautious about =
assigning additional semantics to existing constructs.
> X.509 offers many other ways of signalling a unique/non-standard use.

Thanks for this one paragraph that is somewhat closer to being relevant =
to this thread.

So clearly if one could have a better way for the server to notify the =
client which
certificates it accepts, this would allow selection on other fields of =
the certificates.
Perhaps something like a regexpression in the certificate_authorities =
list, or a
way to express capabilities of certificates.


>=20
> Cheers,
> Anders
>=20
>>=20
>>=20
>> Henry
>>=20
>>=20
>> [1] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html
>>=20
>>=20
>> Social Web Architect
>> http://bblfish.net/
>>=20
>>=20
>=20

Social Web Architect
http://bblfish.net/


From anders.rundgren.net@gmail.com  Sat Dec  7 04:30:01 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CDF1AE2F4 for ; Sat,  7 Dec 2013 04:30:01 -0800 (PST)
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_25=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 LnnVRDSca6NI for ; Sat,  7 Dec 2013 04:29:59 -0800 (PST)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 674A71ADF4E for ; Sat,  7 Dec 2013 04:29:59 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id hn9so1936800wib.13 for ; Sat, 07 Dec 2013 04:29:54 -0800 (PST)
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=mtH+oG8apWd9b+sPafCDIDnDyYBgi8rpvJjucMoMjcs=; b=0HsM334ip28JP1/oD3DcQuuZQ3jrtOqbzPLnTWvyQ2H9ZTecTAgYFQB76ZDbxJo9bj zDyeZCO+IzWFpbNy9JaHAGGCxxi+JXzWjfN9kO1amlsH0nUYWVcOFNN4Eh4pynnVQOZB HXmO6jN/HTsH5ERIEXc973Lk4zNXKfZ3nn3TVyAdt3aVpPiEkXxefsMuRvJTbwyOKqZv uSRdHRtUITTlg4tstSgt/B8V9LVeBKu3o7670tHcL9lDI4Cx8nl2wQbhK6y9utt9zPvs DdqfjeBdIttRp8LX/wiRHrvVYIwmTzjVnyhxrGN6+YRmDRj5YegQ1y3ESsROGMBJlbQl luEQ==
X-Received: by 10.180.74.45 with SMTP id q13mr6631877wiv.47.1386419394818; Sat, 07 Dec 2013 04:29:54 -0800 (PST)
Received: from [192.168.1.99] (33.50.125.78.rev.sfr.net. [78.125.50.33]) by mx.google.com with ESMTPSA id hv5sm5053739wib.2.2013.12.07.04.29.54 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 04:29:54 -0800 (PST)
Message-ID: <52A314BA.4070005@gmail.com>
Date: Sat, 07 Dec 2013 13:29:46 +0100
From: Anders Rundgren 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Henry Story 
References: <5239F4C9.5090805@pobox.com> <01CA3CC6-C3C4-4412-80F8-E7101BA5C209@bblfish.net> <52A301C5.50608@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: TLS Mailing List 
Subject: Re: [TLS] TLS 1.3 wishlist - better certificate selection
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 12:30:01 -0000

On 2013-12-07 13:11, Henry Story wrote:
> 
> On 7 Dec 2013, at 12:08, Anders Rundgren  wrote:
> 
>> On 2013-12-07 11:15, Henry Story wrote:
>>>
>>> On 18 Sep 2013, at 20:45, Michael D'Errico  wrote:
>>>
>>>> A "wish list" for an upcoming new version of TLS is available
>>>> online (I found it via a message on Twitter):
>>>>
>>>> https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf
>>>>
>>>> Is it appropriate to discuss this now, prior to rechartering?
>>>
>>> Hi,
>>>
>>>  One thing that would be nice would be some way of having more flexibility
>>> for the server to request a client certificate. In TLS 1.2 it seems
>>> the only way to do this is to use the certificate_authorities
>>> list. 
>>>
>>>  With WebID over TLS [1] a server may in fact be satisfied if the 
>>> Client certificate contains a WebID in the Subject Alternative Name.
>>> But this then leaves the question open as to how the server can transmit
>>> to the client it's ability to accept such certificates.
>>>
>>> The only solution currently available that I know of 
>>> would be to create a CA with DN such as
>>>
>>>   CN=WebID, O={}
>>>
>>> that every WebID enabled certificate would claim it is signed by (somewhere
>>> in the certificte chain)
>>>
>>> Then this could be passed by the server in the certificate_authorities
>>> list as specified in http://tools.ietf.org/html/rfc5246#section-7.4.6
>>>
>>>
>>> Some people are worried that this would require CAs to resign their root
>>> CAs with a WebID certificate in case they wanted to release WebID 
>>> certificates.
>>>
>>> Is there a better way to do this currently? Could there be a better 
>>> way to do it?
>>
>> I believe we had this discussion before, so here we go again :-)
>> Making TLS CCA (Client Certificate Authentication) useful for consumer authentication (be it to an enterprise, bank or social network), is IMO unrealistic, no matter how desirable it may be.
>>
>> Technical reasons:
>> http://webpki.org/papers/PKI/webauth.pdf#page=1
> 
> This thread is not about your ideas of what is wrong with TLS and
> why you think it can never be solved, but what can be done to improve
> one particular aspect that concerns me.

Well, the issue you bring up is pretty much related to TLS.

> 
> Btw. your article mixes up User Interface issues which can be sorted by 
> browser vendors UI team with protocol issues which I want to discuss here.
> ( Eg: logging out would be easy if the browser showed the client certificate
> used when logged in ).

There's no logout in TLS CCA.

Currently you need a separate non-standard IDP-like thing + browser-specific logout-junk
to "emulate" what any password-using site can do using out-of-the-box solutions.

Tomcat doesn't even permit unknown CAs like required by WebID.

Note it is not WebID that's bad, it is TLS CCA.

> 
> 
>>
>> TLS CCA is also at odds with the market:
>> http://www.forbes.com/sites/amadoudiallo/2013/11/30/google-wants-to-make-your-passwords-obsolete
>>
>> As an authentication solution for VPNs (and even more "secure box-2-box" communication), TLS CCA is great but that's not "le web".
> 
> WebID allows you to use X509 Certs for global authentication without needing to 
> pass through CAs. We are using this every day and building some very cool apps on it. 
> 
>>
>> Regarding the specific WebID issue, I would be cautious about assigning additional semantics to existing constructs.
>> X.509 offers many other ways of signalling a unique/non-standard use.
> 
> Thanks for this one paragraph that is somewhat closer to being relevant to this thread.
> 
> So clearly if one could have a better way for the server to notify the client which
> certificates it accepts, this would allow selection on other fields of the certificates.
> Perhaps something like a regexpression in the certificate_authorities list, or a
> way to express capabilities of certificates.

IMO the best would rather be to nuke TLS CCA as the foundation for WebID.  It is
much_ simpler (note, I didn't say simple...) establishing something based on app-level security.
With WebCrypto you have it today.  With U2F it gets ubiquitous.

TLS 1.3 is as all other versions only about security enhancements.

Cheers
Anders

> 
> 
>>
>> Cheers,
>> Anders
>>
>>>
>>>
>>> Henry
>>>
>>>
>>> [1] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html
>>>
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>>
>>
> 
> Social Web Architect
> http://bblfish.net/
> 


From nmav@redhat.com  Sat Dec  7 05:19:53 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913721ADFA2 for ; Sat,  7 Dec 2013 05:19:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 GqC0NLuVrqZQ for ; Sat,  7 Dec 2013 05:19:51 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id A7A401ADF8D for ; Sat,  7 Dec 2013 05:19:51 -0800 (PST)
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 rB7DJkLv018408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Dec 2013 08:19:46 -0500
Received: from [10.10.59.183] (vpn-59-183.rdu2.redhat.com [10.10.59.183]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rB7DJhZn006248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Dec 2013 08:19:45 -0500
Message-ID: <1386422383.2106.18.camel@aspire.lan>
From: Nikos Mavrogiannopoulos 
To: Brian Smith 
Date: Sat, 07 Dec 2013 14:19:43 +0100
In-Reply-To: 
References:  <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com> <5296C6D7.2040509@dei.uc.pt> <1386332388.3430.22.camel@dhcp-2-127.brq.redhat.com>  <1386335697.3430.31.camel@dhcp-2-127.brq.redhat.com> 
Organization: Red Hat
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
Cc: tls@ietf.org
Subject: Re: [TLS] chacha to replace RC4 (was: Salsa vs. ChaCha)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 13:19:53 -0000

On Fri, 2013-12-06 at 19:44 -0800, Brian Smith wrote:

> AFAICT, there's no technical reason to prohibit AEAD in TLS 1.0 or TLS
> 1.1.
> 
> Also, I don't think TLS 1.2 is that much code to add to a TLS 1.0 or
> TLS 1.1 implementation, especially if you're not supporting any new
> cipher suites except the new ChaCha20 ones, and if you're not trying to
> support any functionality above what what TLS 1.0 and TLS 1.1 provide.
> Consequently, I don't think we should consider the AEAD construction to
> be too much of a burden for anybody to implement in order to support
> new cipher suites.

Hello,  
 I agree that there is no technical reason to prohibit AEAD in
TLS 1.x, x<2, but exactly for this prohibition, the old non-TLS 1.2
supporting implementations don't have support for AEAD. Their design is
often agile in the sense that a new cipher or MAC can be easily added,
but adding an AEAD cipher there is a non-trivial matter. If by AEAD you
mean Adam's draft, then there is also the question why replace
RC4-HMAC-SHA1 with AEAD-CHACHA-POLY1305 when you only need to fix RC4?
(and we have no reasons to believe that HMAC-SHA1 is broken).

If you suggestion is to make CHACHA-HMAC-SHA1 an AEAD design, I don't
think that this is needed. Unlike AEAD-CHACHA-POLY1305 which is
inherently an AEAD design, there is no advantage gained by making
CHACHA-HMAC-SHA1 an AEAD cipher - except for saying "cool it is AEAD",
and making it more difficult for old implementations to use it.

regards, 
Nikos



From mpg@elzevir.fr  Sat Dec  7 05:20:13 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D75C1AE31F for ; Sat,  7 Dec 2013 05:20:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.251
X-Spam-Level: 
X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-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 PSzZjDTQZolK for ; Sat,  7 Dec 2013 05:20:10 -0800 (PST)
Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADFD1ADF8D for ; Sat,  7 Dec 2013 05:20:10 -0800 (PST)
Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 5FD9B16182 for ; Sat,  7 Dec 2013 14:20:05 +0100 (CET)
Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 612D12982E for ; Sat,  7 Dec 2013 14:20:04 +0100 (CET)
Message-ID: <52A32080.3090601@elzevir.fr>
Date: Sat, 07 Dec 2013 14:20:00 +0100
From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
To: tls@ietf.org
References:  <6f16d6d556c68a58918423e0419d31eb.squirrel@www.trepanning.net>
In-Reply-To: <6f16d6d556c68a58918423e0419d31eb.squirrel@www.trepanning.net>
X-Enigmail-Version: 1.6
OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 13:20:13 -0000

On 07/12/2013 00:38, Dan Harkins wrote:
>   It's a balanced PAKE protocol. Like all such schemes (e.g EKE, J-PAKE)
> the database of passwords is presumed to not be available to the
> attacker.
> 
It's not supposed to be available to the attacker, but as CodesInChaos pointed
out, in real life it has an annoying tentency to become available to attackers
much more often than one would like. Anyway, why do you hash & salt the paswords
in the first place, if not to offer some protection in case the database becomes
available to an attacker?

HMAC-SHA256 is a very poor protection, and weak protections are kind of worse
than no protection at all: they give an illusion of security.

Manuel.

From skyper@thc.org  Sat Dec  7 06:05:48 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739A21AE2FF for ; Sat,  7 Dec 2013 06:05:48 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 M0rxQaV-D3qY for ; Sat,  7 Dec 2013 06:05:46 -0800 (PST)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3AC1AE2C8 for ; Sat,  7 Dec 2013 06:05:46 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id qd12so3355300ieb.17 for ; Sat, 07 Dec 2013 06:05:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dOSE7nxbrthCKoUWqj2KuEweGFpzkxZ8pLAo0VG1lik=; b=czywrVRrnjew30qvOZVpyvoRGTlBewkJswTd5BjwDUbWGBZGaOXRpGhqrKQpdnCbab mjJOW8MCXPo7KRLqk1Zc/ScouO9Kreb1kcVsOjX1vxlUHN3mjHJFG4XDjBB3jY+sC9xE Nd9Hkmyt1BjD8baqhrDmXa2xyR7GPHd5ianWg=
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=dOSE7nxbrthCKoUWqj2KuEweGFpzkxZ8pLAo0VG1lik=; b=Hc1P+qSlsATkN9D8sMwYjVMZFf7VB4HX8GvpNoFh1k/7W8HrbhUo5lZGfYh09g0I6O OJd8OLiLpzR7M2LFdCvFdk5PStvpPhzCN93jKswm4UyGDoIGsTTSGpDkvbn8PXXtY4a0 sDiTf1izYCbdtdd9VoiG6d8XQ02hPyw+SmMrlQZqAjKgYlVZQtGdIws4NpgLD8Y/1q+4 p6cur8C6H1hS82SPTQ0Io7auRRvOBhIjoUnl5LgVNq4xcNhqi3iVFPtzTb5F/h331CAO Aj68KoDt4YdEAtRkCP7SoryPvoxOPzxkFnjkLC5+Yw0kgf4KDK5ftTTZw0JR54xqM6+n Zk4g==
X-Gm-Message-State: ALoCoQloEDfgxM1xetJaDKSBYxbpC/l/3wxLvctuqgdIr0mT+VHA5HZ3iJGrHKK+51AnHwIvKkCC
MIME-Version: 1.0
X-Received: by 10.50.136.201 with SMTP id qc9mr6812978igb.11.1386425141824; Sat, 07 Dec 2013 06:05:41 -0800 (PST)
Received: by 10.64.9.41 with HTTP; Sat, 7 Dec 2013 06:05:41 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <52A2FB32.30004@gmail.com>
References:    <52A2FB32.30004@gmail.com>
Date: Sat, 7 Dec 2013 14:05:41 +0000
Message-ID: 
From: Ralf Skyper Kaiser 
To: Yaron Sheffer 
Content-Type: multipart/alternative; boundary=089e01229ed816732e04ecf2429e
Cc: "tls@ietf.org" 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 14:05:48 -0000

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

Hi Yaron,

TLS Version Pinning:
I do not have a solution for the cluster situation but I assume that the
same problem exists for pinning of the certificate. It should be solved the
same way.

I think this would solve the fallback issue in an elegant way with a
feature that is anyway already coming to the browsers and without protocol
modifications.

CIPHER-SUITE Pinning:
We are already making the judgment call which ciphers are NULL, WEAK and
STRONG. If I use 'STRONG' on my first connect I would not like to be
downgraded to WEAK even that in general I would like to have weak enabled
in my browser for other websites.


regards,

ralf



On Sat, Dec 7, 2013 at 10:40 AM, Yaron Sheffer wrote:

> Hi Ralf,
>
> I like the idea of pinning the version number, but I don't think it will
> work well in clusters without significant tinkering (i.e., protocol
> changes): the client connects to cluster member A which has just upgraded
> to TLS 1.3 and immediately pins that server to 1.3. Now it connects to
> another cluster member which is still on TLS 1.2, and the connection is
> reset.
>
> I don't understand how you could pin "ECDHE" - you would need to define
> whether DHE is better or worse than ECDHE, and I don't think we want to
> make that judgment call.
>
> Thanks,
>         Yaron
>
>
> On 12/07/2013 12:31 AM, Ralf Skyper Kaiser wrote:
>
>> Hi,
>>
>> the draft only concerns HTTPS (no other client side implementation
>> attempts a reconnect when it receives
>> a RST on  TLS 1.x [which is bad to start with but apparently necessary]).
>>
>> A solution that solves some of the mentioned problems without any
>> protocol change is
>> to pin the TLS version the same way as certificates are pinned. And
>> while pinning the TLS
>> version it should also be considered to pin the cipher suite ("Use this
>> cipher suite or
>> a better one").
>>
>> After first connect the client will not allow any lesser security (TLS
>> 1.3, ECDHE, ..) than the one
>> used on last connect.
>>
>> regards,
>>
>> ralf
>>
>>
>> On Wed, Nov 27, 2013 at 1:42 AM, Brian Smith > > wrote:
>>
>>     On Mon, Nov 25, 2013 at 3:27 PM, Adam Langley >     > wrote:
>>      >   In the event that a client is making a fallback connection, it
>>      > includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
>>      > current server which sees this cipher suite in a ClientHello SHOULD
>>      > return a fatal alert, inappropriate_fallback (86) and abort the
>>      > connection.
>>
>>     Adam, I think what you propose makes sense. However, I think it might
>>     not be ideal if there are any circumstances where the browser could
>>     accidentally fall back to a lower version--e.g. falling back after a
>>     timeout or falling back in response to the connection being reset.
>>     AFAICT, we currently have to do fallback from TLS 1.2 -> TLS 1.1 and
>>     from TLS 1.1 -> TLS 1.0 in response to connection resets. There will
>>     be some false positives here. In addition to potentially reducing the
>>     security of the connection, these fallback connections add a lot of
>>     latency. If we attempt a fallback connection in response to a
>>     connection reset, and we receive an inappropriate_fallback alert, then
>>     we'd have to make yet *another* connection without the fallback. All
>>     other things being equal, it would be better if the server could
>>     respond respond exactly as it would with a TLS 1.2 ClientHello,
>>     without downgrading the cipher suite or any other feature, more like
>>     what Martin Rex suggested.
>>
>>     However, I don't think it is realistic to backport features all the
>>     way to SSL 3.0. The information in the TLS extensions is too
>>     important, and trying to define good defaults for missing extensions
>>     that make sense long-term seems like it will just bind our hands too
>>     much in the future.
>>
>>     So, we should could consider backporting TLS 1.2 cipher suites to TLS
>>     1.1 and TLS 1.0, but then using your suggested inappropriate_fallback
>>     for for SSL 3.0 handshakes only.
>>
>>     Whether this complication is justified depends on how frequently we
>>     receive false-positive connection resets (and anything else that can
>>     be a false positive) and how much we care about optimizing performance
>>     for that case.
>>
>>     Cheers,
>>     Brian
>>     --
>>     Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
>>     _______________________________________________
>>     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
>

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


Hi Yaron,

TLS Version Pin=
ning:
I do not have a solution for the cluster situation but I ass=
ume that the same problem exists for pinning of the certificate. It should =
be solved the same way.


I think this would solve the fallback issue in an elegant wa=
y with a feature that is anyway already coming to the browsers and without =
protocol modifications.

CIPHER-SUITE Pinning:<=
br>

We are already making the judgment call which ciphers are NULL, WEAK =
and STRONG. If I use 'STRONG' on my first connect I would not like =
to be downgraded to WEAK even that in general I would like to have weak ena=
bled in my browser for other websites.




regards,

ralf



On Sat, Dec 7, 2013 at 10:40 AM, Ya=
ron Sheffer <yaronf.ietf@gmail.com> wrote:


Hi Ralf,



I like the idea of pinning the version number, but I don't think it wil=
l work well in clusters without significant tinkering (i.e., protocol chang=
es): the client connects to cluster member A which has just upgraded to TLS=
 1.3 and immediately pins that server to 1.3. Now it connects to another cl=
uster member which is still on TLS 1.2, and the connection is reset.




I don't understand how you could pin "ECDHE" - you would need=
 to define whether DHE is better or worse than ECDHE, and I don't think=
 we want to make that judgment call.



Thanks,

=A0 =A0 =A0 =A0 Yaron




On 12/07/2013 12:31 AM, Ralf Skyper Kaiser wrote:



Hi,



the draft only concerns HTTPS (no other client side implementation

attempts a reconnect when it receives

a RST on =A0TLS 1.x [which is bad to start with but apparently necessary]).=




A solution that solves some of the mentioned problems without any

protocol change is

to pin the TLS version the same way as certificates are pinned. And

while pinning the TLS

version it should also be considered to pin the cipher suite ("Use thi=
s

cipher suite or

a better one").



After first connect the client will not allow any lesser security (TLS

1.3, ECDHE, ..) than the one

used on last connect.



regards,



ralf





On Wed, Nov 27, 2013 at 1:42 AM, Brian Smith <brian@briansmith.org

<mailto:brian@=
briansmith.org>> wrote:



=A0 =A0 On Mon, Nov 25, 2013 at 3:27 PM, Adam Langley <agl@google.com

=A0 =A0 <mailto:agl@=
google.com>> wrote:

=A0 =A0 =A0> =A0 In the event that a client is making a fallback connect=
ion, it

=A0 =A0 =A0> includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher s=
uites. A

=A0 =A0 =A0> current server which sees this cipher suite in a ClientHell=
o SHOULD

=A0 =A0 =A0> return a fatal alert, inappropriate_fallback (86) and abort=
 the

=A0 =A0 =A0> connection.



=A0 =A0 Adam, I think what you propose makes sense. However, I think it mig=
ht

=A0 =A0 not be ideal if there are any circumstances where the browser could=


=A0 =A0 accidentally fall back to a lower version--e.g. falling back after =
a

=A0 =A0 timeout or falling back in response to the connection being reset.<=
br>
=A0 =A0 AFAICT, we currently have to do fallback from TLS 1.2 -> TLS 1.1=
 and

=A0 =A0 from TLS 1.1 -> TLS 1.0 in response to connection resets. There =
will

=A0 =A0 be some false positives here. In addition to potentially reducing t=
he

=A0 =A0 security of the connection, these fallback connections add a lot of=


=A0 =A0 latency. If we attempt a fallback connection in response to a

=A0 =A0 connection reset, and we receive an inappropriate_fallback alert, t=
hen

=A0 =A0 we'd have to make yet *another* connection without the fallback=
. All

=A0 =A0 other things being equal, it would be better if the server could
=A0 =A0 respond respond exactly as it would with a TLS 1.2 ClientHello,

=A0 =A0 without downgrading the cipher suite or any other feature, more lik=
e

=A0 =A0 what Martin Rex suggested.



=A0 =A0 However, I don't think it is realistic to backport features all=
 the

=A0 =A0 way to SSL 3.0. The information in the TLS extensions is too

=A0 =A0 important, and trying to define good defaults for missing extension=
s

=A0 =A0 that make sense long-term seems like it will just bind our hands to=
o

=A0 =A0 much in the future.



=A0 =A0 So, we should could consider backporting TLS 1.2 cipher suites to T=
LS

=A0 =A0 1.1 and TLS 1.0, but then using your suggested inappropriate_fallba=
ck

=A0 =A0 for for SSL 3.0 handshakes only.



=A0 =A0 Whether this complication is justified depends on how frequently we=


=A0 =A0 receive false-positive connection resets (and anything else that ca=
n

=A0 =A0 be a false positive) and how much we care about optimizing performa=
nce

=A0 =A0 for that case.



=A0 =A0 Cheers,

=A0 =A0 Brian

=A0 =A0 --

=A0 =A0 Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

=A0 =A0 _______________________________________________

=A0 =A0 TLS mailing list

=A0 =A0 TLS@ietf.org =
<mailto:TLS@ietf.org>

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










_______________________________________________

TLS mailing list

TLS@ietf.org

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





_______________________________________________

TLS mailing list

TLS@ietf.org

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





--089e01229ed816732e04ecf2429e--

From yaronf.ietf@gmail.com  Sat Dec  7 07:02:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB091AE363 for ; Sat,  7 Dec 2013 07:02:41 -0800 (PST)
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 IqcySeJ0MDqT for ; Sat,  7 Dec 2013 07:02:38 -0800 (PST)
Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9DE1ADFD5 for ; Sat,  7 Dec 2013 07:02:38 -0800 (PST)
Received: by mail-ee0-f54.google.com with SMTP id e51so785424eek.13 for ; Sat, 07 Dec 2013 07:02:34 -0800 (PST)
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=5DOCTKjy0UaZyZ6JCHEImUNoVuX1wqe9yaEhGa6WHQk=; b=MiUaocnzS0dotNgtGBkXc3wf9lKvbcd4yzHjl9Mp8fRwc3YoQchixDTuUw+ezoD4TX K2uIEM1+odq7WWhO/CvhEh1vo2EKM9ULL3EvB3cFavwdHubwVEVY08MhfWHrgaF35xg4 RWMTxjXvnx0sl0xMC8BooLkUn8NMPlCzQ+7Wd3Uw0/WNy0oG1Ri/JL8cW9b9XfZQPFrh 19j2p/tI+Qht2eCLkGV3n/7iy25iJ1HvYMP5UleiMJAMwqH6NoftKygO1rkKg4KOx0rw hVRrG2HTY4n/n8D9gOKhx/7lhKQyD0uin+/i7TdwYzE6K3TvB/1GZY7gBGdXIIxWbpAx TkUQ==
X-Received: by 10.15.61.134 with SMTP id i6mr6428018eex.48.1386428553945; Sat, 07 Dec 2013 07:02:33 -0800 (PST)
Received: from [10.0.0.2] ([109.65.142.155]) by mx.google.com with ESMTPSA id h3sm7203412eem.15.2013.12.07.07.02.32 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 07:02:33 -0800 (PST)
Message-ID: <52A33888.80307@gmail.com>
Date: Sat, 07 Dec 2013 17:02:32 +0200
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Ralf Skyper Kaiser 
References: 			<52A2FB32.30004@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 15:02:41 -0000

Hi Ralf,

No, AFAIU the problem does not exist for cert pinning, because there is 
protocol involved. Specifically, the server sends out HTTP headers to 
indicate the pinning and its lifetime. So (for example) you can start by 
changing the certs on all cluster members and only afterwards enable 
pinning on all of them.

Re: cipher-suites, if I'm using ECDHE it doesn't mean that I want future 
DHE connections to fail. It is absolutely legitimate to change t
setting he server's software for some reason, and to thereby also change 
the list of supported ciphersuites. I don't think we can ever reach 
consensus on weak vs. strong cipher-suites on this mailing list, and 
such consensus would be needed to standardize such a solution.

Thanks,
	Yaron

On 12/07/2013 04:05 PM, Ralf Skyper Kaiser wrote:
> Hi Yaron,
>
> TLS Version Pinning:
> I do not have a solution for the cluster situation but I assume that the
> same problem exists for pinning of the certificate. It should be solved
> the same way.
>
> I think this would solve the fallback issue in an elegant way with a
> feature that is anyway already coming to the browsers and without
> protocol modifications.
>
> CIPHER-SUITE Pinning:
> We are already making the judgment call which ciphers are NULL, WEAK and
> STRONG. If I use 'STRONG' on my first connect I would not like to be
> downgraded to WEAK even that in general I would like to have weak
> enabled in my browser for other websites.
>
>
> regards,
>
> ralf
>
>
>
> On Sat, Dec 7, 2013 at 10:40 AM, Yaron Sheffer  > wrote:
>
>     Hi Ralf,
>
>     I like the idea of pinning the version number, but I don't think it
>     will work well in clusters without significant tinkering (i.e.,
>     protocol changes): the client connects to cluster member A which has
>     just upgraded to TLS 1.3 and immediately pins that server to 1.3.
>     Now it connects to another cluster member which is still on TLS 1.2,
>     and the connection is reset.
>
>     I don't understand how you could pin "ECDHE" - you would need to
>     define whether DHE is better or worse than ECDHE, and I don't think
>     we want to make that judgment call.
>
>     Thanks,
>              Yaron
>
>
>     On 12/07/2013 12:31 AM, Ralf Skyper Kaiser wrote:
>
>         Hi,
>
>         the draft only concerns HTTPS (no other client side implementation
>         attempts a reconnect when it receives
>         a RST on  TLS 1.x [which is bad to start with but apparently
>         necessary]).
>
>         A solution that solves some of the mentioned problems without any
>         protocol change is
>         to pin the TLS version the same way as certificates are pinned. And
>         while pinning the TLS
>         version it should also be considered to pin the cipher suite
>         ("Use this
>         cipher suite or
>         a better one").
>
>         After first connect the client will not allow any lesser
>         security (TLS
>         1.3, ECDHE, ..) than the one
>         used on last connect.
>
>         regards,
>
>         ralf
>
>
>         On Wed, Nov 27, 2013 at 1:42 AM, Brian Smith
>         
>         >> wrote:
>
>              On Mon, Nov 25, 2013 at 3:27 PM, Adam Langley
>         
>              >> wrote:
>               >   In the event that a client is making a fallback
>         connection, it
>               > includes TLS_FALLBACK_SCSV (0x5600) in the list of
>         cipher suites. A
>               > current server which sees this cipher suite in a
>         ClientHello SHOULD
>               > return a fatal alert, inappropriate_fallback (86) and
>         abort the
>               > connection.
>
>              Adam, I think what you propose makes sense. However, I
>         think it might
>              not be ideal if there are any circumstances where the
>         browser could
>              accidentally fall back to a lower version--e.g. falling
>         back after a
>              timeout or falling back in response to the connection being
>         reset.
>              AFAICT, we currently have to do fallback from TLS 1.2 ->
>         TLS 1.1 and
>              from TLS 1.1 -> TLS 1.0 in response to connection resets.
>         There will
>              be some false positives here. In addition to potentially
>         reducing the
>              security of the connection, these fallback connections add
>         a lot of
>              latency. If we attempt a fallback connection in response to a
>              connection reset, and we receive an inappropriate_fallback
>         alert, then
>              we'd have to make yet *another* connection without the
>         fallback. All
>              other things being equal, it would be better if the server
>         could
>              respond respond exactly as it would with a TLS 1.2 ClientHello,
>              without downgrading the cipher suite or any other feature,
>         more like
>              what Martin Rex suggested.
>
>              However, I don't think it is realistic to backport features
>         all the
>              way to SSL 3.0. The information in the TLS extensions is too
>              important, and trying to define good defaults for missing
>         extensions
>              that make sense long-term seems like it will just bind our
>         hands too
>              much in the future.
>
>              So, we should could consider backporting TLS 1.2 cipher
>         suites to TLS
>              1.1 and TLS 1.0, but then using your suggested
>         inappropriate_fallback
>              for for SSL 3.0 handshakes only.
>
>              Whether this complication is justified depends on how
>         frequently we
>              receive false-positive connection resets (and anything else
>         that can
>              be a false positive) and how much we care about optimizing
>         performance
>              for that case.
>
>              Cheers,
>              Brian
>              --
>              Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
>              _________________________________________________
>              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
>     
>
>

From skyper@thc.org  Sat Dec  7 07:14:21 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9951AE371 for ; Sat,  7 Dec 2013 07:14:21 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 l4kGFZjvKlFz for ; Sat,  7 Dec 2013 07:14:20 -0800 (PST)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 11FFC1ADF7A for ; Sat,  7 Dec 2013 07:14:19 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id x13so3395154ief.20 for ; Sat, 07 Dec 2013 07:14:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KdRBx4n4ETH74PJW/477s/kBpPVvBZB9PvjlejVfzfs=; b=PVPL9UEJ/gDxIh6zDE2D+0QY7xN3WyIAaTrHtb4zDd/6szQZGYmqDflR4wtV+t+gUn OuagFFi6F4x3TGUcJzjnC8ztEO/lMcaeM25DFON/09hhPhMjZpKAIRhDnHcThGL3G4M3 +zgp3061zDsGhIu7Rc81XFJLpNIlix2K0U4xU=
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=KdRBx4n4ETH74PJW/477s/kBpPVvBZB9PvjlejVfzfs=; b=EMWQMtuyyI7JhpQFD+YZhr6w9dnhXCg//TMT2LlzXe5A5Xyg/f2qzhJ2DCXN6x5jZd 4LUtxRa9m/5zb0wOGlPm6enn37rkOYspbXuKQFHt5oU5x3ojUpxetf2eOGPZ1erNQUd0 fADgIUhq+5RDYrqokTCmnynR0jnc8ufDMCa8iFmxfXvgRZ7lWbwcelLRoCEZ9xubWYqy 17xLh2cdPDwbbD2Tyk70/TG7p6sbWXTCe+8/A7+UZK7UlRt+8LXcgOgxgGWhGh+Im4/8 PqAcYnqFB0h1JvwekJWG5dezP+TB9uUSdti1rFduRikeUh4LmkOdjI/MER3OzJxoYa86 rDgA==
X-Gm-Message-State: ALoCoQmxTOwZwbEyb2CaFucEIMUnovcdJ8dsCENs8roORlyAdT9M8BNGGvqB88ja2tXiF7lIKnvH
MIME-Version: 1.0
X-Received: by 10.50.136.201 with SMTP id qc9mr7069059igb.11.1386429255926; Sat, 07 Dec 2013 07:14:15 -0800 (PST)
Received: by 10.64.9.41 with HTTP; Sat, 7 Dec 2013 07:14:15 -0800 (PST)
X-Originating-IP: [203.118.14.76]
In-Reply-To: <52A33888.80307@gmail.com>
References:    <52A2FB32.30004@gmail.com>  <52A33888.80307@gmail.com>
Date: Sat, 7 Dec 2013 15:14:15 +0000
Message-ID: 
From: Ralf Skyper Kaiser 
To: Yaron Sheffer 
Content-Type: multipart/alternative; boundary=089e01229ed84e5cbb04ecf337bc
Cc: "tls@ietf.org" 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 15:14:21 -0000

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

Hi


On Sat, Dec 7, 2013 at 3:02 PM, Yaron Sheffer  wrote:

> Hi Ralf,
>
> No, AFAIU the problem does not exist for cert pinning, because there is
> protocol involved. Specifically, the server sends out HTTP headers to
> indicate the pinning and its lifetime. So (for example) you can start by
> changing the certs on all cluster members and only afterwards enable
> pinning on all of them.
>

This feature could be optional and a server admin could decide to use this
feature (e.g. to advertise TLS Version pinning and CIpher-suite pinning).

A server-cluster can opt-out to use the feature.

I'm not yet giving up hope to also find a solution that makes this feature
available to server-clusters. It could be a technical solution or a
management/process solution.


>
> Re: cipher-suites, if I'm using ECDHE it doesn't mean that I want future
> DHE connections to fail. It is absolutely legitimate to change t
> setting he server's software for some reason, and to thereby also change
> the list of supported ciphersuites. I don't think we can ever reach
> consensus on weak vs. strong cipher-suites on this mailing list, and such
> consensus would be needed to standardize such a solution.
>

Sadly can we not make up our mind which ciphers are strong or weak and we
always shift this responsibility to the server-admin. We have done so in
the past and solving this now would be out-of-scope for the proposed
TLS-version/Cipher-suite pinning discussion.


>
> Thanks,
>         Yaron
>
>
regards,

ralf

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


Hi


On Sat, Dec 7, 2013 at 3:02 PM, Yaron Sheffer <yaronf=
.ietf@gmail.com> wrote:


Hi Ralf,



No, AFAIU the problem does not exist for cert pinning, because there is pro=
tocol involved. Specifically, the server sends out HTTP headers to indicate=
 the pinning and its lifetime. So (for example) you can start by changing t=
he certs on all cluster members and only afterwards enable pinning on all o=
f them.



This feature could be optional and a serve=
r admin could decide to use this feature (e.g. to advertise TLS Version pin=
ning and CIpher-suite pinning).

A server-cluster can opt-=
out to use the feature. 


I'm not yet giving up hope to also find a solution that makes this =
feature available to server-clusters. It could be a technical solution or a=
 management/process solution.
=A0



Thanks,

=A0 =A0 =A0 =A0 Yaron


regards,

ralf



--089e01229ed84e5cbb04ecf337bc--

From mpg@elzevir.fr  Sat Dec  7 07:33:48 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB05A1AE37D for ; Sat,  7 Dec 2013 07:33:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.251
X-Spam-Level: 
X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-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 Z48ALpyEYre2 for ; Sat,  7 Dec 2013 07:33:45 -0800 (PST)
Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) by ietfa.amsl.com (Postfix) with ESMTP id 560EB1AE37A for ; Sat,  7 Dec 2013 07:33:45 -0800 (PST)
Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 9953516182 for ; Sat,  7 Dec 2013 16:33:38 +0100 (CET)
Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 454942982E for ; Sat,  7 Dec 2013 16:33:37 +0100 (CET)
Message-ID: <52A33FD0.7040708@elzevir.fr>
Date: Sat, 07 Dec 2013 16:33:36 +0100
From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
To: tls@ietf.org
References: 			<52A2FB32.30004@gmail.com>  <52A33888.80307@gmail.com>
In-Reply-To: <52A33888.80307@gmail.com>
X-Enigmail-Version: 1.6
OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 15:33:48 -0000

Hi,

On 07/12/2013 16:02, Yaron Sheffer wrote:
> No, AFAIU the problem does not exist for cert pinning, because there is 
> protocol involved. Specifically, the server sends out HTTP headers to 
> indicate the pinning and its lifetime. So (for example) you can start by 
> changing the certs on all cluster members and only afterwards enable 
> pinning on all of them.
> 
Maybe I'm missing something obvious, but it seems to me the problem with version
pinning could be solved by explicitly stating the minimum TLS version in the
HTTP headers, then. That way, cluster admins could upgrade some servers to say
1.3 while keeping the pinning on 1.2, and then update the pinning to 1.3 only
when all the servers in the cluster are upgraded to 1.3.

Manuel.

From skyper@thc.org  Sat Dec  7 09:01:46 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DACF1AE3BD for ; Sat,  7 Dec 2013 09:01:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.357
X-Spam-Level: 
X-Spam-Status: No, score=-0.357 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, MISSING_HEADERS=1.021, 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 WMhCPZ6vpkRO for ; Sat,  7 Dec 2013 09:01:44 -0800 (PST)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C96B61AE05E for ; Sat,  7 Dec 2013 09:01:44 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id x13so3518998ief.34 for ; Sat, 07 Dec 2013 09:01:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=DRDXkn5dQQWk0NJEoUEtt+ERIyA6f5o8gvQ2EanJ2rc=; b=TngelgP2VVtvISkowfMO0NmRRKCKX2PMCHj4hMVRhd5YKMXeR3EnsoaD+oJym5+nhf Nt3MImH12wWsvNTSPBAEvvokJm6ceCvrmy15DJpsfNLO1H3ore7akyctwta9c3+w1hcm Xq7rloqna+2yaodvl3wGudaNg1nKWTRqsmEUc=
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:cc:content-type; bh=DRDXkn5dQQWk0NJEoUEtt+ERIyA6f5o8gvQ2EanJ2rc=; b=VFPrJTJe4e10WWXi53vptQ5Wg1ayOwSNGnbJ7qMqe8zxxCnYebp3F/Zho3eXfderEK LWGgKBpbbePvlzHnBQ0flNZzWxRU9eR9RclzY7p1b8aP7cuZZvgyyU2O/VU6lfQ4Gz6V FFSG9dLfisgahbnje3XIM/1iPq/JHjqOJ7Uoo20TM3K3DgNB5/PHC5Blg90aId+CIchn yORmBvkfNW76RTXq1T3A259BCV5b6kFgKQQF+oAgkoqLhbFmE5sfWojqu6MQkF6nskF8 SRka7yR3FfVxsKPtdoU+EO/B8BbqRZb9rtX3Nsg9fXmoIVahpAbpz1gYLRHiEONHqkH7 069Q==
X-Gm-Message-State: ALoCoQl9gHctU3ojJAanWM7R3QpcHfd9+iLQFwEu0LQrreKR+oZbrX6rYyM7248h77aYwbh+gWty
MIME-Version: 1.0
X-Received: by 10.50.23.103 with SMTP id l7mr8488625igf.3.1386435700605; Sat, 07 Dec 2013 09:01:40 -0800 (PST)
Received: by 10.64.9.41 with HTTP; Sat, 7 Dec 2013 09:01:40 -0800 (PST)
X-Originating-IP: [213.52.184.7]
In-Reply-To: <52A33FD0.7040708@elzevir.fr>
References:    <52A2FB32.30004@gmail.com>  <52A33888.80307@gmail.com> <52A33FD0.7040708@elzevir.fr>
Date: Sat, 7 Dec 2013 17:01:40 +0000
Message-ID: 
From: Ralf Skyper Kaiser 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0158aaba70825204ecf4b704
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 17:01:46 -0000

--089e0158aaba70825204ecf4b704
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

goo idea.

Another idea is to disable TLS-version pinning on the all servers until all
servers are upgraded to 1.3 and
 then enable TLS version pinning again.

Lets assume the client has TLS 1.2 pinned and the admin wants to upgrade to
TLS 1.3.

While pinning is disabled (short period of time) all clients who have
already pinned the TLS 1.2 will connect to TLS 1.3 put not pin TLS 1.3.
This way the clients can connect to other servers in the cluster that are
still running on TLS 1.2. Once all servers have been upgraded the admin can
turn on pinning again and on next connect the client will update the min.
allowed TLS version to 1.3 (or whatever the highest supported version by
the client is).

regards,

ralf


On Sat, Dec 7, 2013 at 3:33 PM, Manuel P=E9gouri=E9-Gonnard wrote:

> Hi,
>
> On 07/12/2013 16:02, Yaron Sheffer wrote:
> > No, AFAIU the problem does not exist for cert pinning, because there is
> > protocol involved. Specifically, the server sends out HTTP headers to
> > indicate the pinning and its lifetime. So (for example) you can start b=
y
> > changing the certs on all cluster members and only afterwards enable
> > pinning on all of them.
> >
> Maybe I'm missing something obvious, but it seems to me the problem with
> version
> pinning could be solved by explicitly stating the minimum TLS version in
> the
> HTTP headers, then. That way, cluster admins could upgrade some servers t=
o
> say
> 1.3 while keeping the pinning on 1.2, and then update the pinning to 1.3
> only
> when all the servers in the cluster are upgraded to 1.3.
>
> Manuel.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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


Hi,

goo idea.

Another idea is to disable TLS-version pinning on the al=
l servers until all servers are upgraded to 1.3 and
=A0then enable TLS v=
ersion pinning again.



Lets assume the client has TLS 1.2 pinned and the admin want=
s to upgrade to TLS 1.3.

While
 pinning is disabled (short period of time) all clients who have already
 pinned the TLS 1.2 will connect to TLS 1.3 put not pin TLS 1.3. This=20
way the clients can connect to other servers in the cluster that are=20
still running on TLS 1.2. Once all servers have been upgraded the admin=20
can turn on pinning again and on next connect the client will update the
 min. allowed TLS version to 1.3 (or whatever the highest supported=20
version by the client is).


regards,

ralf


On Sat, Dec 7, 2013 at 3:33 PM, Manuel P=E9gouri=E9-=
Gonnard <mpg@elzevir.fr> wrote:


Hi,




On 07/12/2013 16:02, Yaron Sheffer wrote:

> No, AFAIU the problem does not exist for cert pinning, because there i=
s

> protocol involved. Specifically, the server sends out HTTP headers to<=
br>
> indicate the pinning and its lifetime. So (for example) you can start =
by

> changing the certs on all cluster members and only afterwards enable
> pinning on all of them.

>


Maybe I'm missing something obvious, but it seems to me the probl=
em with version

pinning could be solved by explicitly stating the minimum TLS version in th=
e

HTTP headers, then. That way, cluster admins could upgrade some servers to =
say

1.3 while keeping the pinning on 1.2, and then update the pinning to 1.3 on=
ly

when all the servers in the cluster are upgraded to 1.3.



Manuel.


_____________________=
__________________________

TLS mailing list

TLS@ietf.org

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





--089e0158aaba70825204ecf4b704--

From dharkins@lounge.org  Sat Dec  7 15:21:06 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BF21AE454 for ; Sat,  7 Dec 2013 15:21:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.567
X-Spam-Level: 
X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 8tCs4eXNvUSw for ; Sat,  7 Dec 2013 15:21:05 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E3E491AE44F for ; Sat,  7 Dec 2013 15:21:04 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id F17B11022404C; Sat,  7 Dec 2013 15:20:59 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 7 Dec 2013 15:21:00 -0800 (PST)
Message-ID: <499f3256234d13c6522a250bfd9371d9.squirrel@www.trepanning.net>
In-Reply-To: <52A32080.3090601@elzevir.fr>
References:  <6f16d6d556c68a58918423e0419d31eb.squirrel@www.trepanning.net> <52A32080.3090601@elzevir.fr>
Date: Sat, 7 Dec 2013 15:21:00 -0800 (PST)
From: "Dan Harkins" 
To: Manuel =?iso-8859-1?Q?P=E9gouri=E9-Gonnard?= 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 23:21:06 -0000

On Sat, December 7, 2013 5:20 am, Manuel Pégourié-Gonnard wrote:
> On 07/12/2013 00:38, Dan Harkins wrote:
>>   It's a balanced PAKE protocol. Like all such schemes (e.g EKE, J-PAKE)
>> the database of passwords is presumed to not be available to the
>> attacker.
>>
> It's not supposed to be available to the attacker, but as CodesInChaos
> pointed
> out, in real life it has an annoying tentency to become available to
> attackers
> much more often than one would like. Anyway, why do you hash & salt the
> paswords
> in the first place, if not to offer some protection in case the database
> becomes
> available to an attacker?

  Originally the passwords were not salted but I received a comment
recommending that it be done.

> HMAC-SHA256 is a very poor protection, and weak protections are kind of
> worse
> than no protection at all: they give an illusion of security.

  I'm assuming you don't know of an efficient pre-image attack.
So I will assume you're referring to the ability of someone to do
a dictionary attack given the database of salted passwords. And in
that case, yes, this is not that big protection. Modular exponentiation
(used by augmented PAKE schemes) is not much better either. And
given the coWPAtty (and family) attacks against WPA-PSK that uses
PBKDF2 with 4096 iterations of HMAC-SHA1 I would say that's not
too good either.

  So when an attacker has a database of protected passwords you
should assume the worst regardless of how you protect the
passwords.

  Let me point out yet again that this draft is not proposing a general
purpose cipher suite that is appropriate for all situations. If it is not
appropriate for your TLS deployment then by all means don't use it.
But just because it is not appropriate for your particular deployment
does not mean it is not appropriate for anyone.

  regards,

  Dan.



From anders.rundgren.net@gmail.com  Sat Dec  7 03:06:16 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619131AE2CE for ; Sat,  7 Dec 2013 03:06:16 -0800 (PST)
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_25=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 qrsJOR0qMgcF for ; Sat,  7 Dec 2013 03:06:15 -0800 (PST)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id EFEDA1AE2D4 for ; Sat,  7 Dec 2013 03:06:14 -0800 (PST)
Received: by mail-we0-f176.google.com with SMTP id w62so1659429wes.21 for ; Sat, 07 Dec 2013 03:06:10 -0800 (PST)
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=76YQDa11lpeupgm2pZ72yHx3tlmSlTiHrNXGC/IlQoY=; b=TfT821kDolBJhZ6BxZrwA9xvRvOkb9KEDpflU8ZT+HcFC9IS+qtr4Sgrjzp8MwLFDk zvKdLA7XcEG861cHYlONX2tmc4RMskXzt2wocTqkwLwFl6xwvkR1dx02CRlVUrqkHG7T kEfhQ34FfQvGx9PD45Us3LlwRQxVkwvu4wskIi7tb3LMeev7Dh/SX/hhweSierngeXob DJ83HpWtIHzx9VCx/qY8rm/8CVCZGhZUDECjwTMRM5n1xVOfXFHwSa6LM41RI3xyve+M qIcpFqh7FhZt687TYwPsbGwYTBfQCI7GEsdcAxePAWHPHk7t4XGq+2h9axQYb0tPJo1R IWMw==
X-Received: by 10.180.91.11 with SMTP id ca11mr6454651wib.39.1386414370437; Sat, 07 Dec 2013 03:06:10 -0800 (PST)
Received: from [192.168.1.99] (33.50.125.78.rev.sfr.net. [78.125.50.33]) by mx.google.com with ESMTPSA id fj8sm3496109wib.1.2013.12.07.03.06.09 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 03:06:10 -0800 (PST)
Message-ID: <52A3011A.8070903@gmail.com>
Date: Sat, 07 Dec 2013 12:06:02 +0100
From: Anders Rundgren 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Henry Story ,  Michael D'Errico 
References: <5239F4C9.5090805@pobox.com> <01CA3CC6-C3C4-4412-80F8-E7101BA5C209@bblfish.net>
In-Reply-To: <01CA3CC6-C3C4-4412-80F8-E7101BA5C209@bblfish.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sun, 08 Dec 2013 19:42:32 -0800
Cc: TLS Mailing List , public-webid WebID Group 
Subject: Re: [TLS] TLS 1.3 wishlist
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 07 Dec 2013 11:06:16 -0000

On 2013-12-07 11:15, Henry Story wrote:
> 
> On 18 Sep 2013, at 20:45, Michael D'Errico  wrote:
> 
>> A "wish list" for an upcoming new version of TLS is available
>> online (I found it via a message on Twitter):
>>
>> https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf
>>
>> Is it appropriate to discuss this now, prior to rechartering?
> 
> Hi,
> 
>   One thing that would be nice would be some way of having more flexibility
> for the server to request a client certificate. In TLS 1.2 it seems
> the only way to do this is to use the certificate_authorities
> list. 
> 
>   With WebID over TLS [1] a server may in fact be satisfied if the 
> Client certificate contains a WebID in the Subject Alternative Name.
> But this then leaves the question open as to how the server can transmit
> to the client it's ability to accept such certificates.
> 
> The only solution currently available that I know of 
> would be to create a CA with DN such as
> 
>    CN=WebID, O={}
> 
> that every WebID enabled certificate would claim it is signed by (somewhere
> in the certificte chain)
> 
> Then this could be passed by the server in the certificate_authorities
> list as specified in http://tools.ietf.org/html/rfc5246#section-7.4.6
> 
> 
> Some people are worried that this would require CAs to resign their root
> CAs with a WebID certificate in case they wanted to release WebID 
> certificates.
> 
> Is there a better way to do this currently? Could there be a better 
> way to do it?

I believe we had this discussion before, so here we go again :-)
Making TLS CCA (Client Certificate Authentication) useful for consumer authentication (be it to an enterprise, bank or social network), is IMO unrealistic, no matter how desirable it may be.

Technical reasons:
http://webpki.org/papers/PKI/webauth.pdf#page=1

TLS CCA is also at odds with the market:
http://www.forbes.com/sites/amadoudiallo/2013/11/30/google-wants-to-make-your-passwords-obsolete

As an authentication solution for VPNs (and even more "secure box-2-box" communication), TLS CCA is great but that's not "le web".

Regarding the specific WebID issue, I would be cautious about assigning additional semantics to existing constructs.
X.509 offers many other ways of signalling a unique/non-standard use.

Cheers,
Anders

> 
> 
> Henry
> 
> 
> [1] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html
> 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 


From brian@briansmith.org  Mon Dec  9 05:33:18 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8421ADF75 for ; Mon,  9 Dec 2013 05:33:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.08
X-Spam-Level: 
X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 bdP2WCXBayrY for ; Mon,  9 Dec 2013 05:33:16 -0800 (PST)
Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 806C21AE2BF for ; Mon,  9 Dec 2013 05:32:58 -0800 (PST)
Received: by mail-qe0-f42.google.com with SMTP id b4so2845224qen.1 for ; Mon, 09 Dec 2013 05:32:53 -0800 (PST)
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=onJwdN0KV4ZuaZzmXWg6J4Bm8ZbgK1T7IVz3HO8ovgw=; b=WE9dmO0prAB1tx/RIxBizcwhSjuCsgRAV9CHVdflgqxUuCLK+7SInTvnrgEBCziK4x CoHpVtX4wxUK0G6QCWRry25I1o5z+uim+LL5AcMi6Lsl49l6K6NSEdQOeQEt3G6OgJz7 wEN3Q2MYl2prY0quGpX3+09tk6ionzdAh0JHo5WyiGuSapShbC/L1UxhXNWRvFI3/6LC 4Ihd8diXWn/QlHlJ6dRgzaAz0jp9hxRT/fvW09p53JhddzyASjMqzmwD7CBmJ/iq7kT0 6Tqn203MpyAkPFYnILDV2uUs+kxBDK6ig89rX76BmtF4n6wmrHDt5/h4FPttC7JTvzpM 6YtQ==
X-Gm-Message-State: ALoCoQlmCcAJx47piZoVBZSldVqWxKVW3Go4wCEZpQSXxjUWS+JRKjgDMzOKU0HYv/Fsa7t+EShv
MIME-Version: 1.0
X-Received: by 10.229.194.1 with SMTP id dw1mr32762670qcb.20.1386595973594; Mon, 09 Dec 2013 05:32:53 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Mon, 9 Dec 2013 05:32:53 -0800 (PST)
X-Originating-IP: [12.216.141.3]
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>   
Date: Mon, 9 Dec 2013 05:32:53 -0800
Message-ID: 
From: Brian Smith 
To: Andrei Popov 
Content-Type: text/plain; charset=UTF-8
Cc: "" , Peter Gutmann 
Subject: Re: [TLS] ALPN concerns
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 13:33:18 -0000

Hi Andrei,

Sorry for the delay. Please see replies inline.

On Tue, Nov 19, 2013 at 11:42 AM, Andrei Popov
 wrote:
> I totally agree that we need to encrypt more information in the TLS handshake,
> including the client cert and the contents of various extensions, such as SNI and ALPN.
> Unfortunately, the only way to make this information confidential in the existing versions
> of TLS is to incur additional round-trips (by using renegotiation, or otherwise exchanging
> messages after the TLS handshake is complete). This is one of the reasons why the TLS
> WG is pushing hard to make progress on TLS1.3.

Unfortunately, like I said in my previous message, I think it will be
extremely difficult, and probably impossible, for us to encrypt the
ALPN (and SNI) part of the handshake in TLS 1.3 if we standardize and
deploy the current ALPN design. As soon as we start using it, web
browsers will have a compatibility burden to continue sending the
unencrypted ALPN header in their ClientHello, because we won't be able
to assume that the server supports TLS 1.3's encrypted ALPN.

Note that this is not a problem for NPN because NPN does not disclose
any information in the ClientHello. We can completely change how
protocol negotiation works in TLS 1.3, and clients that support NPN
could seemlessly transition to the new mechanism without risking any
negative compatibility or performance impact.

>> As far as I've been led to believe, ALPN exists primarily to allow MitM to more easily
>> inspect what protocol the application is speaking and possibly block the application,
>> with as low of a cost to the MitM as possible--i.e. exactly the opposite goal of
>> everything we discussed at IETF88 in perpass and in other discussions.
>
> No, ALPN exists primarily to negotiate an application protocol without incurring extra
> round-trips, to allow the server to pick the application protocol and present the
> corresponding identity, and to align with the existing TLS extensions.

I have discussed the ALPN vs NPN issue with Eric Rescorla (co-chair of
this working group, alongside Joseph Salowey from Cisco) multiple
times, and each time Eric said that allowing passive MitM devices to
know which protocol is being used is important, and that this is an
advantage for ALPN over NPN. I will let him explain why, if it hasn't
already been explained on the list. FWIW, I strongly disagree that it
should be a goal to allow passive MitM to know which protocol is being
used. In fact, I think that we should have a goal of protecting the
protocol information so that passive MitM has a much more difficult
time of determining with certainty the protocol being used.

>>I think that in many cases, traffic analysis that relies on timing information will be
>>able to tell with a high degree of accuracy which protocol has been selected for use
>>on the connection. However, traffic analysis cannot tell us what protocols were
>> offered but *not* selected.
>
> Correct, and NPN offers the list of the application protocols in clear-text, so it does
> not solve this problem.

NPN does solve this problem *for the client*. NPN does not solve the
problem for the server. However, in the context of web browsers doing
normal web browsing stuff (as opposed to DTLS in WebRTC), the client's
privacy is fundamentally more important than the server's privacy in
this respect. Additionally, if you have a publicly-accessible server
on the internet, people could always probe it (with either ALPN or
NPN) to determine which protocols, which versions of protocols, and
likely which implementations of those protocols are available, so
protecting the server's privacy in this regard is futile. Conversely,
protecting the client's privacy is much more practical and useful. We
have seen, for example, how the Tor protocol attempts to make its TLS
handshake look like a browser's handshakes in order to thwart blocking
filtering of the Tor protocol.

> If we can avoid application protocol negotiation at the TLS layer without incurring additional round-trips, I am in full support. Looking forward to the write-up.

I am sorry that I've yet to create an internet draft describing the
idea. However, hopefully the following description, which is
copy-pasted from a private email sent to others previously, describes
the idea clearly enough. Note that some things need to be refined;
e.g. what happens when the client guesses the server's ECDH parameter
requirements wrongly.

First, let's assume that we can restrict things to ephemeral key
exchange mechanisms: TLS_ECDHE_* and TLS_DHE_*. For simplicity, let's
restrict things further and talk about TLS_ECDHE_*. Also, let's assume
for now that we don't care about the case where there are client
certificates.

Let's imagine that a client can guess the 1-3 most likely curves that
the server is likely to choose for the ECDHE key exchange. That is
actually pretty easy now, even without any prior contact to the
server, because the server is almost always going to choose P-256,
P-384, P-521, in that order. So, the client could presumptuously
generate its own private/public keypair for those 1-3 curves before it
even connects to the server, right? Well, then it could just include
the public keys in an extension in its client hello, right? Then, when
the server has finished its ServerHello...ServerHelloDone, it has
enough information to send ChangeCipherSuite and Finished just like a
resumption handshake. That is, we've transformed the TLS full
handshake from a 2-RTT, client-sends-application-data-first handshake
into a 1-RTT server-sends-application-data-first handshake that is
equivalent to the 2-RTT version, in terms of security properties.
(Compare this to False Start or Snap Start, which both have weaker
security properties.) In other words, it is better performance
effectively for free.

Now, In order for the client and server to agree to do this, they have
to agree on it via some TLS extension--namely, the TLS extension that
contains the client's public keys. Now, imagine that this same
extension also contained a number N which means "the first four bytes
of application data contain a number N; following that are N bytes of
application data are actually connection-specific metadata that is
prefixed to the actual application data."

The peer TLS implementation would process these N bytes of metadata by
reading them and exposing them to the application through some API,
and then passing the actual application data to the application.

What kind of metadata would be in this header? At a minimum, I would
expect that the server would include information such as what
protocols it supports (replacing NPN), whether the server is HSTS
(i.e. bringing HSTS to IMAP, SMTP, POP, IRC, etc.), the server's key
pinning information (replacing HPKP), and whether the server wants to
force OCSP stapling (replacing the Must-Staple header that I will
propose soon). For the client, it would include information such as
what protocol it has chosen to speak (replacing NPN) and its channel
ID key/proof of possession (replacing channel ID).

Above, I just described a TLS handshake that looks like this:

H ClientHello
  (Client Key)  ---------------->
                <---------------- H ServerHello
                                  H Certificate
                                  H CertificateStatus
                                  H ServerKeyExchange
                                  H ServerHelloDone
                                  H NewSessionTicket
                                  C ChangeCipherSpec
                                  H Finished
                                  A Trust Metadata
C ChangeCipherSpec ------------->
H Finished
A Trust Metadata
A Application data <------------> A Application data


Now, we might worry that some intermediaries will choke on this
strange-looking handshake? Can we turn it into something that they
won't choke on? Yes, we can:

H ClientHello
H (Client Key)  ---------------->
                <---------------- H ServerHello
                                    (Server Key)
                                  C ChangeCipherSpec
                                  H Finished
                                  A Certificate
                                  A CertificateStatus
                                  A ServerKeyExchange
                                  A ServerHelloDone
                                  A NewSessionTicket
                                  A Trust Metadata
C ChangeCipherSpec ------------->
H Finished
A Trust Metadata
A Application data <------------> A Application data

Note that all the application data records are encrypted so the
intermediary can't read them--that is, it can't tell the difference
between metadata and actual application data, so it looks like this to
them:

H ClientHello
H (Client Key)  ---------------->
                <---------------- H ServerHello
                                    (Server Key)
                                  C ChangeCipherSpec
                                  H Finished
                                  A Application data
C ChangeCipherSpec ------------->
H Finished
A Application data <------------> A Application data

I.e. it looks exactly like the server false start handshake to an
outside observer. This should minimize the compatibility impact of
supporting the mechanism.

Besides creating a framework similar to "encrypted extensions" that
you could use for channel ID, this also gives us encrypted session
tickets, which means that there is a certain amount of unlinkability
between connections that wasn't there originally. Further, making the
Certificate and CertificateStatus messages opaque to outsiders allows
us to apply compression to those parts of the handshake without
worrying about intermediates choking on the compressed data. And/or we
can define new, non-X.509 certificate formats without fear of breakage
by intermediaries. We could also add back client certificates by
adding Certificate and CertificateVerify messages before the client's
Metadata. This would give us encrypted client certificates. Also, by
mandating TLS 1.2 for this mechanism, we can overload it as a TLS
downgrade prevention mechanism (if we can solve the
downgrade-to-SSL3.0-without-extensions issue). If we were to establish
some standards for padding session tickets to a certain size, then the
client could always send a session ticket in every client hello
(either a real one, or a randomly-generated one of the right size).
This would, I hope, eliminate the possibility to determine whether or
a handshake is a resumption handshake or a full handshake--i.e. mask
whether or not the user has visited the site before/recently.
(Measuring the timing of the server's side of the handshake would give
things away, but that is a harder attack to pull off.)

At a higher level, this breaks TLS into three distinct phases: (1) TLS
is the layer that establishes the keys and authenticates the
connection with those keys, mutually anonymously, (2) the Trust
Metadata phase is where the TLS stack and the application work
together to establish trust of the peer and of the peer's data, and
(3) the application data phase is well, the application data. Given
this, we could say that the TLS working group is responsible for
defining the first phase (TLS) while perhaps some other groups could
define the second phase (Trust Metadata). My hope is that the trust
metadata layer might be useful even in non-TLS protocols.

Cheers,
Brian

From SRS0=5/mU=VQ=acm.org=bmoeller@srs.kundenserver.de  Mon Dec  9 05:53:20 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C6A1AE2BD for ; Mon,  9 Dec 2013 05:53:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 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.001, SPF_HELO_PASS=-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 a1NRu3J3G-Qo for ; Mon,  9 Dec 2013 05:53:19 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 607E31ADEBB for ; Mon,  9 Dec 2013 05:53:18 -0800 (PST)
Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0M3OD6-1VYDN233Fg-00qxVk; Mon, 09 Dec 2013 14:53:13 +0100
Received: by mail-oa0-f48.google.com with SMTP id l6so3820866oag.21 for ; Mon, 09 Dec 2013 05:53:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cyjoTpjTYiRGxN60DPEXYT2NWwL/Lr7zOsSz48vnCjo=; b=gvmGGu4ksF/r2TmJkkAR6gBrgw92jMdzIxcIXN4cLYK1I8xU+fIgXpQgotJzAWRE3n pQltVF0m2cVETXRXCtQSWBvQcl3EB1xezH8c/UHgN5gSg3hCqs0cjBXI2Qtmmdxd68VJ tf3M04azFAePm0vwA+MPXHrNQdTKZatNq7FIuLwhZxBsmXdHv4d2F3lGm+lS/0lcNRev 0pTz5yKOwS7unWQiZvyNLZ5iZMXPMgCJBJvxJ3NqeVwg0gMwIbvp0Lp03+6IEJ601pJQ vTuyr8TP1QfTtr7Fnxd54khv8BTQABvEC1FEW9dTbidD6UFyYFKk4vAPAm7P9Mb5+aWd xYOg==
MIME-Version: 1.0
X-Received: by 10.60.70.134 with SMTP id m6mr12427861oeu.14.1386597191519; Mon, 09 Dec 2013 05:53:11 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Mon, 9 Dec 2013 05:53:11 -0800 (PST)
In-Reply-To: <20131206182527.98EA51AB3C@ld9781.wdf.sap.corp>
References:  <20131206182527.98EA51AB3C@ld9781.wdf.sap.corp>
Date: Mon, 9 Dec 2013 14:53:11 +0100
Message-ID: 
From: Bodo Moeller 
To: Martin Rex 
Content-Type: multipart/alternative; boundary=001a1133458e0c148304ed1a5124
X-Provags-ID: V02:K0:bRSeHon38MdjlVRlVKLi7tj5hVQKKgdI+pYC5hdY6uQ 9jicLMBPMvt15J0+P9KpAKn8+KcQ3qdxFtDX9hHpp7tmLtWe8J tnybVUd4kL8lW0CpJLs/NviYoedi62AQZ4KXx2sj4zkweVo4p7 iu61WPqNn0duX3jWty1q2tbSRNFll37b2w9qascdz4QUQPoC/o vytGiyhIKfJL9s7L7TRlBN5GRxYwwg7Fnz60lqQhpTfIUSAslp TpinxzuaHoCrEFi/FlOcaaFBuX+0OaStBKs79x0RPYEue+fGoD AzzbEkx1JZJdPPvQX2DS8TcnGUiLbvNwTsk8xSG0fwQUYbY4fQ d1DqnYGsq8+26SBMWXJgekcZSOwt6vZ6gK2sO9yR3meUxxQzPN wvG/hXmqDa5GH7Snn96AqhtNNeUJlsd5uexlSNLsiCcr/8Rxyo Q2WMw
Cc: "tls@ietf.org" 
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 13:53:58 -0000

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

Martin Rex :


> > We can start to use TLS_FALLBACK_SCSV
> > ASAP to improve security *ASAP* for connections to *those* servers that
> do
> > get updated (80% or even just 10% is better than 0% -- if only the most
> > important servers that users trust get updated, that's something).
>
> Huh?  Your proposal is not going to improve the security one single bit.

[....] the use of the TLS_FALLBACK_SCSV will either *NOT* affect the rest
> of the TLS protocol not at all, or cause a fatal handshake failure.
> And very few, if any at all, of the situations where the handshake fails,
> will be instances of an active attack.  And it remains extremely
> questionable, when the handshake would succeed, that the attacker
> will gain anything at all.
>

To be entirely clear, there's obviously no security improvement from
TLS_FALLBACK_SCSV for clients that never use fallback connections, and for
servers that only have clients without such fallback strategies.

The older protocol versions have some very real security problems.  I don't
think it's relevant that, as far as we know, these security problems are
not currently routinely exploited by attackers.



> For this feature to work at all, the prerequisite is that both
> communication
> peers must be updated.  When looking at a protocol feature that requires
> both communication peers to be updated as a prerequisite, wouldn't it be
> preferable to fix those protocol features of SSL/TLS that we deem necessary
> for reliable security to become negotiable even in the "most conservative"
> ClientHello that clients are willing to fallback to?


Deploying TLS_FALLBACK_SCSV on even just a single server is sufficient to
protect connections to that server.  Clients can use it without having to
wait for all servers to be updated.

If we can also get all servers fixed so that there's no longer a need for
potentially insecure fallback connections, all the better, but it's
certainly going to take longer before clients can be updated to benefit
from that kind of change.  The TLS_FALLBACK_SCSV specification does not
prevent any such effort -- we don't have to choose between *either*
deploying TLS_FALLBACK_SCSV *or* fixing the protocol properly.  (The
TLS_FALLBACK_SCSV Internet-Draft is intentionally agnostic about what a
proper fix would look like.  Once we manage to fix the protocol, clients
would simply stop to send TLS_FALLBACK_SCSV, while servers would continue
to watch for it.)

So I don't agree with the word "preferable": it suggests that the options
are mutually exclusive, when in fact they are not.

Bodo

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


Mart=
in Rex <mrex@sap.com>:
=A0



> We can start to use TLS_FALLBACK_SCSV

> ASAP to improve security *ASAP* for connections to *those* servers tha=
t do

> get updated (80% or even just 10% is better than 0% -- if only the mos=
t

> important servers that users trust get updated, that's something).=





Huh? =A0Your proposal is not going to improve the security one single=
 bit.

[....] the use of the TLS_FALLBACK_SCSV will either *NOT* affect the rest
of the TLS protocol not at all, or cause a fatal handshake failure.

And very few, if any at all, of the situations where the handshake fails,
will be instances of an active attack. =A0And it remains extremely

questionable, when the handshake would succeed, that the attacker

will gain anything at all.

To be entire=
ly clear, there's obviously no security improvement from TLS_FALLBACK_S=
CSV for clients that never use fallback connections, and for servers that o=
nly have clients without such fallback strategies.



The older protocol versions have some very real securit=
y problems. =A0I don't think it's relevant that, as far as we know,=
 these security problems are not currently routinely exploited by attackers=
.






For this feature to work at all, the prerequisite is that both communicatio=
n

peers must be updated. =A0When looking at a protocol feature that requires<=
br>
both communication peers to be updated as a prerequisite, wouldn't it b=
e

preferable to fix those protocol features of SSL/TLS that we deem necessary=


for reliable security to become negotiable even in the "most conservat=
ive"

ClientHello that clients are willing to fallback to?

<=
/div>
Deploying TLS_FALLBACK_SCSV on even just a single server is suffi=
cient to protect connections to that server. =A0Clients can use it without =
having to wait for all servers to be updated.



If we can also get all servers fixed so that there'=
s no longer a need for potentially insecure fallback connections, all the b=
etter, but it's certainly going to take longer before clients can be up=
dated to benefit from that kind of change. =A0The TLS_FALLBACK_SCSV specifi=
cation does not prevent any such effort -- we don't have to choose betw=
een *either* deploying TLS_FALLBACK_SCSV *or* fixing the protocol properly.=
 =A0(The TLS_FALLBACK_SCSV Internet-Draft is intentionally agnostic about w=
hat a proper fix would look like. =A0Once we manage to fix the protocol, cl=
ients would simply stop to send TLS_FALLBACK_SCSV, while servers would cont=
inue to watch for it.)



So I don't agree with the word "preferable&quo=
t;: it suggests that the options are mutually exclusive, when in fact they =
are not.

Bodo


--001a1133458e0c148304ed1a5124--

From brian@briansmith.org  Mon Dec  9 05:56:50 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB1B1ADF85 for ; Mon,  9 Dec 2013 05:56:49 -0800 (PST)
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 kmdDyG8K7cvs for ; Mon,  9 Dec 2013 05:56:46 -0800 (PST)
Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9C91ADF52 for ; Mon,  9 Dec 2013 05:56:46 -0800 (PST)
Received: by mail-qe0-f48.google.com with SMTP id gc15so2794807qeb.7 for ; Mon, 09 Dec 2013 05:56:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=/Mcedk7VTs/j3O/yStUrRviZ3alJloq6Ql4QsL3Iv4A=; b=SxNt0QIO98LZRLOff6VudCb7f69+xiZwbn06cYVVXLi3pAdHfG3H9RDG8ispBbFS0h Fe+ZM6xpFtd0iI0xojbBbRARo5hqtaYZZaZGFsw4LnYRc2tS8AO9OiQUfnD4jtEggliz lSISMjC1wz1XTVVNCMaBhoPZBFCRk6AnOb74XezNs6iMNYNfTAK6M+G2WSwPVOH6d4+H 8TIoeOrYXfA3e3GpyLaTwehZPVkArSFbIewuwN5yfoF6r9yz99NB/oDomRIFFEUXpMox HafwWoQukyvJ51WsMlDKJido0HcAad78pFntXps6v81EepxWXgntjFVuK6D2PBQqGf/2 8QNg==
X-Gm-Message-State: ALoCoQmbsZX87Y6xeQQ51Y6iCzcLcXZ/6WGCY34zPBqyCaGSwzIboF4ByqiS7F1IJTSM62vIG9Y6
MIME-Version: 1.0
X-Received: by 10.224.66.5 with SMTP id l5mr33928620qai.31.1386597401535; Mon, 09 Dec 2013 05:56:41 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Mon, 9 Dec 2013 05:56:41 -0800 (PST)
X-Originating-IP: [12.216.141.3]
Date: Mon, 9 Dec 2013 05:56:41 -0800
Message-ID: 
From: Brian Smith 
To: Xiaoyong Wu 
Content-Type: text/plain; charset=UTF-8
Cc: "" , Peter Gutmann 
Subject: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re:  ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 13:56:50 -0000

On Mon, Nov 18, 2013 at 9:58 PM, Brian Smith  wrote:
> I think that in many cases, traffic analysis that relies on timing
> information will be able to tell with a high degree of accuracy which
> protocol has been selected for use on the connection. However, traffic
> analysis cannot tell us what protocols were offered but *not*
> selected.

I have found a particularly interesting case where ALPN is less secure than NPN.

Please see http://tools.ietf.org/html/draft-nottingham-http2-encryption-01#section-2.1
(read the whole document, but section 2.1 is especially interesting).
That document defines a mechanism wherein, through protocol
negotiation, a web browser and server can agree on a "relaxed" form of
TLS for HTTP where the client does not authenticate the server's
certificate. The goal is to enable a form of opportunistic encryption
to HTTP.

The case where the server does not use a certificate that the client
would verify correctly as it would in the "normal" HTTPS case is not
interesting. However, the case where opportunistic encryption is being
used with a certificate that *is* valid (as defined by RFC5280, et
al.) is interesting.

Consider the case of an attacker that is willing and able to actively
MitM traffic but does not want to get caught, so they are only willing
to actively MitM traffic when they know they can get away with it. I
believe this describes a lot of attackers, including the ones that are
motivating the perpass effort.

Consider a client that uses the ALPN extension to advertise that it
supports http2-tls-relaxed and regular http2. The presence of the
"http2-tls-relaxed" token in the ALPN extension in the ClientHello is
effectively saying "You will get away with performing an active MitM
attack against me" i.e. "Please MitM me, sir." The type of attacker
describe above simply needs to MitM any/all such connections, choosing
the "http2-tls-relaxed" protocol for all of them, while leaving alone
all connections that do not advertise the http2-tls-relaxed protocol.

Now, consider a client and server that agree to use NPN to negotiate
between "http2-tls-relaxed" and regular http2. In NPN, the server
advertises which protocols it supports, and the client chooses which
protocol to use. Thus, the MitM does not have ultimate control over
which protocol is selected. If the active MitM tries to offer only
"http2-tls-relaxed" on a connection to force a MitM-able connection,
it runs the risk of getting caught if/when the client doesn't support
"http2-tls-relaxed".

Further, in the NPN case, a pssive MitM cannot even learn whether
http2-tls-relaxed or regular authenticated http2 was negotiated on the
connection, because the client's choice of "http2-tls-relaxed" vs
"http2" was hidden from the passive MitM. Thus, a passive MitM cannot
even learn whether a particular client supports the
"http2-tls-relaxed" option or not. Hiding this from the attacker is
useful because it makes it harder for the attacker to coordinate
future (active) attacks.

Note that the choice between "http2-tls-relaxed" and "http2" only
affects (AFAICT) the validation of the certificate. It doesn't change,
in a detectable way, the data that is sent on the connection.
Consequently, traffic analysis cannot be used to differentiate
"http2-tls-relaxed" from "http2". Thus, we've found a counterexample
to disprove the claim that we don't need to hide what protocol was
used because traffic analysis can always be used to determine which
protocol was negotiated.

Cheers,
Brian

From nmav@redhat.com  Mon Dec  9 06:08:09 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAA71AE304 for ; Mon,  9 Dec 2013 06:08:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 ekBaAtzI49MH for ; Mon,  9 Dec 2013 06:08:07 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 636D41ADF7F for ; Mon,  9 Dec 2013 06:08:07 -0800 (PST)
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 rB9E7rZs009828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Dec 2013 09:07:54 -0500
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 rB9E7oiB032027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 09:07:51 -0500
Message-ID: <1386598070.2375.25.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Brian Smith 
Date: Mon, 09 Dec 2013 15:07:50 +0100
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>    
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
Cc: "" , Peter Gutmann 
Subject: Re: [TLS] ALPN concerns
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 14:08:09 -0000

On Mon, 2013-12-09 at 05:32 -0800, Brian Smith wrote:

> >> As far as I've been led to believe, ALPN exists primarily to allow MitM to more easily
> >> inspect what protocol the application is speaking and possibly block the application,
> >> with as low of a cost to the MitM as possible--i.e. exactly the opposite goal of
> >> everything we discussed at IETF88 in perpass and in other discussions.
> >
> > No, ALPN exists primarily to negotiate an application protocol without incurring extra
> > round-trips, to allow the server to pick the application protocol and present the
> > corresponding identity, and to align with the existing TLS extensions.
> 
> I have discussed the ALPN vs NPN issue with Eric Rescorla (co-chair of
> this working group, alongside Joseph Salowey from Cisco) multiple
> times, and each time Eric said that allowing passive MitM devices to
> know which protocol is being used is important, and that this is an
> advantage for ALPN over NPN. I will let him explain why, if it hasn't
> already been explained on the list. FWIW, I strongly disagree that it
> should be a goal to allow passive MitM to know which protocol is being
> used. In fact, I think that we should have a goal of protecting the
> protocol information so that passive MitM has a much more difficult
> time of determining with certainty the protocol being used.

I think we need to clarify not only the reason we need the protocol
negotiation in TLS but most importantly, how we expect implementations
to support it.

If we expect a lightweight super-server or a firewall to do the mapping
of the incoming protocol requests in the client hello to the appropriate
servers, then having NPN means that the firewall or super-server has to
terminate TLS in order to discover the intended protocol. That's pretty
unacceptable in many scenarios, not only because of the unnecessary load
on the firewall/super-server, but also because it makes TLS client
authentication very hard to impossible.

If we expect that the incoming protocol requests will be handled by a
single server application (that is no super-servers or a firewall will
be involved to distribute the protocols)... then NPN suits that
scenario, and provides more than ALPN. However one server handling all
possible protocols feels like a very restricted use-case.

regards,
Nikos



From brian@briansmith.org  Mon Dec  9 07:22:56 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FFA1AE338 for ; Mon,  9 Dec 2013 07:22:56 -0800 (PST)
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 jlIl25dxm5eI for ; Mon,  9 Dec 2013 07:22:53 -0800 (PST)
Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5CC1AE2B3 for ; Mon,  9 Dec 2013 07:22:53 -0800 (PST)
Received: by mail-qe0-f41.google.com with SMTP id gh4so2868452qeb.14 for ; Mon, 09 Dec 2013 07:22:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=mXBoEx2Qry6wvCRjWjb1sOxuhzt8H+pqvoEZHyLfsHY=; b=J6zaUP/5JaZhw7qnLLvNHNxkZ44hqoejCZch1U728YQjUi0O4pbfD4gsaQJcxbA1mA 2fkSS9nq4Rd7fQ1L5jjiw5fZVHDRbXsDWDmfrm5rMSFpGSk0ZQRQrOI1ag6KxJKHlg0I 99yiJhusXDg/Fnhawc7NRGI8wTFRVZivgFL7qqSh3ff7wnYKF6o9UiFqI3qQMgiiuf4N tnGOY2m0WcIyypr9UiuHJkXJ2W06WPyFdRJsO+xyvpfC+pHtdpExSivG1gArueW4HBby PAcexgMZAI+4C/L3CosThIKJX2Wr2VKDn1oq9N3XfNH8jUrEzCqofTv767aQL+93YE+s m06A==
X-Gm-Message-State: ALoCoQlDISqzET0zcv9EWtvKr7nhece/2KYsj7xz0O3q6tJhRkOyR9scFkMAbZ6u8S/CNXeeMWuY
MIME-Version: 1.0
X-Received: by 10.49.84.195 with SMTP id b3mr34345265qez.32.1386602568507; Mon, 09 Dec 2013 07:22:48 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Mon, 9 Dec 2013 07:22:48 -0800 (PST)
X-Originating-IP: [12.216.141.3]
Date: Mon, 9 Dec 2013 07:22:48 -0800
Message-ID: 
From: Brian Smith 
To: "" 
Content-Type: text/plain; charset=UTF-8
Subject: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 15:22:56 -0000

Hi all,

My name is Brian Smith and I am the lead on Mozilla Corporation's work
on TLS, PKI, and some related things (though *not* DTLS or other
WebRTC networking stuff, which EKR does a fine job of leading). I am
primarily responsible for working to secure Firefox, but most of my
work also applies to Thunderbird and other software based on our
"Gecko" engine. Note also that Mozilla has implemented APIs to allow
certain kinds of HTML5 applications to make TCP connections in a way
that enables them to implement any TCP protocol (SMTP, IMAP, etc.),
not just HTTP, SPDY, and WebSockets. Therefore, our interest in
protocol negotiation goes much further than negotiating just HTTP/1
vs. HTTP/2, though that is by far the most important use case for us.

For the reasons I note below, I think we should re-evaluate whether we
still have consensus on moving forward with recommending ALPN as the
protocol negotiation mechanism to be used in TLS and specifically in
HTTP/2. I would like the working group to re-consider the option of
recommending the more secure and more private NPN mechanism instead,
at least until TLS 1.3 can offer an even better alternative mechanism.

In IETF86, there was some kind of vote in favor of ALPN over NPN. I
could not attend that IETF for personal reasons, so I don't know the
nature of the vote or how binding it is and whatnot. Also, I know ALPN
has gone through WGLC already. I regret that I chose to voice my
opposition to ALPN only privately to EKR before IETF86 and during
WGLC. That was definitely a mistake on my part, and I'm truly sorry
for making it.

Since IETF86, and since WGLC, there have been new developments. I
tried to go into detail on many of them in the "ALPN concerns" thread,
but here is a summary:

* During the summer, the Edward Snowden stuff happened, making us
(more) aware of widespread, worldwide, spying on the users of our
software. If nothing else, I hope we have learned from Snowden's work
that we need to be particularly careful to maximize privacy from
network attackers in the protocols and software we create.

* Stephen Farrell published the first draft of "Pervasive Monitoring
is an Attack" [0], which states (in part; please read the whole
thiing):

   The technical plenary of IETF 88 [IETF88Plenary]
   discussed pervasive monitoring and participants
   had strong agreement that this was an attack and
   one that should be mitigated where possible via
   the design of protocols that make pervasive
   monitoring significantly more expensive or
   infeasible.
   ...

   For the purposes of this BCP "pervasive monitoring"
   means very widespread privacy-invasive gathering of
   protocol artefacts including application content,
   protocol meta-data (such as headers) or keys
   used to secure protocols.
   ...
   This BCP simply records the consensus to design
   protocols so as to mitigate the attack, where possible.

Note that the protocol/options metadata that would be negotiated in
ALPN or NPN or whatever is protocol metadata. I think there is no
disputing that NPN (or a new design that works more like NPN) helps
make attacks more expensive, even though it may not make any attack
impossible, and that switching from NPN to ALPN would only help
facilitate attacks.

* Joseph Salowey wrote the first draft of a proposed new charter for
the TLS Working Group [1]. That draft says, in part:

    o Develop a mode that encrypts as much of
      the handshake as is possible to reduce
      the amount of observable data to both
      passive and active attackers.

Thus, standardizing unencrypted ALPN now seems likely to be in direct
contradiction to our future charter.

* During IETF88, EKR published the TLS 1.3 flows draft [2]. This draft
is extremely helpful for seeing that TLS 1.3 is likely to be quite
complex, even before we try to encrypt the ALPN and/or SNI extensions
in the ClientHello. Also, it does not show a viable means of
encrypting the ALPN extension in a backward-compatible (with
unencrypted ALPN) way. (A mechanism for encrypting ALPN would have to
do so without adding any round trips to be viable.) Thus, the idea
that we can standardize unencrypted ALPN now, and then somehow fix it
in TLS 1.3, seems extremely unrealistic.

* During IETF87, Microsoft suggested that we need to extend protocol
negotiation to support the negotiation of options. My understanding is
that we should expect the HTTP WG to specify some such options in
HTTP. AFAICT, the need for ALPN or NPN to support an open-ended set of
negotiated information in addition to the protocol was not considered
when considering the security of ALPN.

* Mark Nottingham wrote his Opportunistic Encryption for HTTP URIs
draft [3], which is a specific example of option negotiation described
in the previous point. Mark also wrote [4] that he is concerned that
the HTTP 2.0 work may not be able to go forward without a viable means
of doing opportunistic encryption.

* I described [5] (I recommend reading the whole thread, despite how
many words there are in it) several technical objections to switching
to ALPN from NPN on privacy and security groups, and noted that NPN is
still much more widely deployed and generally meets our goals better.

* I also described [6] how choosing ALPN over NPN would weaken the
security properties of Mark's Opportunistic Encryption for HTTP draft.
It is hard to see how it would be reasonable to do opportunistic
encryption using Mark's proposed mechanism on top of ALPN, considering
the significant weakness ALPN adds to it, that NPN doesn't.

* In [6], I also showed that it isn't necessarily true that traffic
analysis can yield information equivalent to ALPN, which was a key
argument in favor of ALPN. Note that this is just the simplest
possible example. I think we can be much more successful against
traffic analysis in general, by adding features to TLS that make
traffic analysis difficult, such as [7], and I actually don't
understand why we gives any credence to the "traffic analysis makes
the argument moot" argument; that seems very defeatist to me. Perfect
traffic analysis prevention may be impractically expensive, but it is
far from clear that imperfect traffic analysis is worthless. Tor is a
pretty good but imperfect mechanism for preventing traffic analysis,
and it seems to work surprisingly well.

* I described [8] a potential solution for moving the
application-level protocol negotiation out of the TLS protocol in "TLS
1.3" without hurting performance, at least in common cases.

I don't have any political position in the argument of ALPN vs. NPN
vs. whatever. My concerns are purely technical and purely based on my
desire to maximize privacy and security for the users of my software
and even my competitors' software. It is clear to me that ALPN is
strictly worse than NPN in terms of protecting privacy and security of
users. (FWIW, it would literally be easier for me to add ALPN support
to Firefox than it would be for me to have typed up all these messages
to the working group mailing list.)

We can argue about whether ALPN is "good enough" (and I've argued
extensively it isn't) but I fail to see why we should settle for
something worse at all, especially when the choice of NPN better suits
the motto of the IETF, "rough consensus and running code," as
demonstrated by the large number of *deployed-in-production* NPN
implementations. (If you used a web browser today, you probably used
NPN). Therefore, I strongly encourage people to choose NPN instead of
ALPN, which is my strong preference for Firefox, Thunderbird, and
other Mozilla products. And, I would be very happy to do all the
editing work on the NPN draft to get it into shape for being a
proposed standard.

Cheers,
Brian

[0] http://tools.ietf.org/html/draft-farrell-perpass-attack-00
[1] http://www.ietf.org/mail-archive/web/tls/current/msg10759.html
[2] http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00
[3] http://tools.ietf.org/html/draft-nottingham-http2-encryption-01
[4] http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1453.html
[5] http://www.ietf.org/mail-archive/web/tls/current/msg10405.html
[6] http://www.ietf.org/mail-archive/web/tls/current/msg10890.html
[7] http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00
[8] http://www.ietf.org/mail-archive/web/tls/current/msg10888.html

[

From alfredo@pironti.eu  Mon Dec  9 07:23:18 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC951AE2B3 for ; Mon,  9 Dec 2013 07:23:18 -0800 (PST)
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, 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 X7a7IPQtcwWV for ; Mon,  9 Dec 2013 07:23:16 -0800 (PST)
Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1DD1AE326 for ; Mon,  9 Dec 2013 07:23:16 -0800 (PST)
Received: by mail-oa0-f52.google.com with SMTP id h16so3996137oag.11 for ; Mon, 09 Dec 2013 07:23:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6LAUYG5tFKWlYLNRZsJ79KVc+VPlzz+2WsrNfECUceY=; b=IT/9iuu2wjMlOPXoLB1cKE6+ktLbFexgz+yndO7kqhygg+0fzlpq0m5XHl+fSPmQeR asIobC3n/zOn/fTYIYSrAlNLSv/a0cZBTNt+EgpEbrdZit9884B9RvTLG9vanCtQGood GUwl0SSM1hZWPyIUB4fspQ+dg/dg6Tl1yz2RE=
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=6LAUYG5tFKWlYLNRZsJ79KVc+VPlzz+2WsrNfECUceY=; b=ILaffAjCStSQa9TkCkm8Ekgfw4iTVpLRIqIoNnGZFS9L8JCNCadqTVnh3vGk7fZ05A Sgrne6ioR95XrV/qk2kU2zaIdN6tx0M+sDHxWE7cDq4k51u7+tOkpicuP1rp+TMXhRQC urA5yUiJmCHRpFxYqROMQj61IEfAogRZcPwQR+srn8STKKU764+GGkHLkLssbVjjdbrj Q97TQjpJMJGcgm4c1YwioY4nCsK1TyQAk56E7hiR/KLeyFJ0negkB8So0uS1w89r9qha wONXfhlSQI+cg+SvTrjQ/SqlrfR/48X78vt311R+SqdPVG0FXNF2MazqFUrC89xtcnVj 5avw==
X-Gm-Message-State: ALoCoQl7mJRBZl1SKbVDVcZVuUY4sAJHDzbbuYKnktWUgkxrsHlaerHsXDpK33lEZCojejbKZy+a
MIME-Version: 1.0
X-Received: by 10.60.39.169 with SMTP id q9mr1035466oek.79.1386602591305; Mon, 09 Dec 2013 07:23:11 -0800 (PST)
Received: by 10.76.180.193 with HTTP; Mon, 9 Dec 2013 07:23:11 -0800 (PST)
X-Originating-IP: [128.93.188.195]
In-Reply-To: 
References: 
Date: Mon, 9 Dec 2013 16:23:11 +0100
Message-ID: 
From: Alfredo Pironti 
To: Brian Smith 
Content-Type: text/plain; charset=UTF-8
Cc: Peter Gutmann , "" 
Subject: Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 15:23:18 -0000

> The case where the server does not use a certificate that the client
> would verify correctly as it would in the "normal" HTTPS case is not
> interesting. However, the case where opportunistic encryption is being
> used with a certificate that *is* valid (as defined by RFC5280, et
> al.) is interesting.

I think this pre-condition makes your counter-example invalid.
A client that only accepts valid certificates is in practice only
implementing http2, not http2-tls-relaxed, in that client's behavior
doesn't change.

>
> Note that the choice between "http2-tls-relaxed" and "http2" only
> affects (AFAICT) the validation of the certificate.

Indeed, but under the assumption that only valid certificates are
accepted, the behaviors coincide to "http2".

Best,
Alfredo

From brian@briansmith.org  Mon Dec  9 08:10:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0281D1AE2DC for ; Mon,  9 Dec 2013 08:10:35 -0800 (PST)
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 Z9iTF8zGciin for ; Mon,  9 Dec 2013 08:10:33 -0800 (PST)
Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0274A1ADFCE for ; Mon,  9 Dec 2013 08:10:32 -0800 (PST)
Received: by mail-qe0-f54.google.com with SMTP id cy11so2898715qeb.41 for ; Mon, 09 Dec 2013 08:10:27 -0800 (PST)
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=snZgCuC622gkyjVML4y6IWJRAkHsxr68/W4ucS1uiKo=; b=WPZ19o+fBAHfHMKIPSUJ/l5wwz9AEV8kc4Ky7v6W61UBv/jawR0VbYRnwQTBRY9LT6 X1e8kX5NPHeOVGXpi/HYatiZc++uk83WwAzI8Bi7QtY7ym37cpgEzKJJKPHMWREzK7c+ 3TjPavY+oP6Lr1LvEGGROWELI4Q2/NICbANmqyQBQ2RsKxa7Xzr46KSJs3ILP7dWb/rg MiKmGr+kSUykz5dBAsBW1e/IjCu2nb76mnBDAt8jRUzARmGtP3GNgV9/gpBVNtlV7F/I lk2stwA+eus2GfRWnWWgo3fOIS8XcWufa82+cJTIW4kWVUseCUdxdgKUg8j7+xf43sxn o0Tw==
X-Gm-Message-State: ALoCoQk3bJhPcqDtLRTY57zWi0xt1UXObDJTMm4CR0nRjLqR22tZoDc6NE2yQWadUgwUFVqbqv1u
MIME-Version: 1.0
X-Received: by 10.224.171.70 with SMTP id g6mr26182333qaz.80.1386605427830; Mon, 09 Dec 2013 08:10:27 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Mon, 9 Dec 2013 08:10:27 -0800 (PST)
X-Originating-IP: [12.216.141.3]
In-Reply-To: 
References:  
Date: Mon, 9 Dec 2013 08:10:27 -0800
Message-ID: 
From: Brian Smith 
To: Alfredo Pironti 
Content-Type: text/plain; charset=UTF-8
Cc: Peter Gutmann , "" 
Subject: Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 16:10:35 -0000

On Mon, Dec 9, 2013 at 7:23 AM, Alfredo Pironti  wrote:
>> The case where the server does not use a certificate that the client
>> would verify correctly as it would in the "normal" HTTPS case is not
>> interesting. However, the case where opportunistic encryption is being
>> used with a certificate that *is* valid (as defined by RFC5280, et
>> al.) is interesting.
>
> I think this pre-condition makes your counter-example invalid.
> A client that only accepts valid certificates is in practice only
> implementing http2, not http2-tls-relaxed, in that client's behavior
> doesn't change.

Let's say the client is connecting to example.org:443 using TLS. There
are two interesting possibilities:

1. The client could be resolving an http:// link that uses
opportunistic encryption. In this case, if the client supports
opportunistic encryption, the client would support "http2-tls-relaxed"
and "http2-tls" (and "http1-tls") and a MitM attack, if attempted,
would succeed.

2. The client could be resolving an https:// link. In this case, the
client would only support "http2-tls" (and "http1-tls") and a MitM
attack, if attempted, would fail in a end-user-notable way.

With ALPN, it is trivial for the MitM to determine which case it is
and act accordingly. With NPN, it is not trivial (it requires
correlating data from multiple connections) and in many cases it may
be impossible (e.g. when an HTTP cache has stored the response with
the alternate-service upgrade header).

> Indeed, but under the assumption that only valid certificates are
> accepted, the behaviors coincide to "http2".

In the case of opportunistic encryption, we would support both valid
and invalid certificates. In the case of normal "http2-tls" and
"http1-tls", we would support only valid certificates.

Cheers,
Brian


-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

From alfredo@pironti.eu  Mon Dec  9 08:40:45 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260981AE30B for ; Mon,  9 Dec 2013 08:40:45 -0800 (PST)
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, 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 e_S2BKNWLGeN for ; Mon,  9 Dec 2013 08:40:43 -0800 (PST)
Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6411AE359 for ; Mon,  9 Dec 2013 08:40:42 -0800 (PST)
Received: by mail-ob0-f170.google.com with SMTP id wp18so4020584obc.29 for ; Mon, 09 Dec 2013 08:40:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TImCgECTtdKxvu6tTWVcMsFNz976GQhgLM7qe/UW2Ds=; b=gw7YZOd8NU/S8eacwd10dm3ns/+AmiWDB6AYpd/o/d9Liw6yr1cAKzRGtuOuHZHqct +qbsJEl4tlgfU4+rWImhuMLvTO4we2/O7RHFAjlNUPFeo1TrPu1LPYg75eHqXrNJLc9V BL7u89mRn72DfNP7ifvtgwmmGyBvDSp+RXurk=
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=TImCgECTtdKxvu6tTWVcMsFNz976GQhgLM7qe/UW2Ds=; b=eZcg9DtDQyZ2/3z1k7d3AoDoPXRj06x9SJmLP5tZQxvJch6s2mCtsp0mdch4qTt8E9 RmhLGoL7a1UT0Ss/a4r176zHCfBztV0ua7ss0j4uAAI66vcpJJOHVdC/vhQPPAWdaDSG vg8gG3l0SIOTFOnj+udBftOJwHZ3/WzDdgCGAr5Ong1P6CstDrKBSqs5UqDKVEkx2jDT DdhGBjJBachMTmjRXXI/2jChO6pn1A7WqEOozBA+XzZJWjufnYYittJaBcdxaNd28w8m 3ZhQNoZvmRiCS8oStB4EorMStkZ7dDYNhwymmhyOmjohq1uYgojdMZ7nMhrTcRiWXiqF JuIg==
X-Gm-Message-State: ALoCoQm140cN079zTIBbjTczbwvQrUDp2oxCKAZVLcjmNuZpPkHtobIS0/MvCfr3z7gdczV+XpLd
MIME-Version: 1.0
X-Received: by 10.60.79.168 with SMTP id k8mr13378604oex.7.1386607237855; Mon, 09 Dec 2013 08:40:37 -0800 (PST)
Received: by 10.76.180.193 with HTTP; Mon, 9 Dec 2013 08:40:37 -0800 (PST)
X-Originating-IP: [128.93.188.195]
In-Reply-To: 
References:   
Date: Mon, 9 Dec 2013 17:40:37 +0100
Message-ID: 
From: Alfredo Pironti 
To: Brian Smith 
Content-Type: text/plain; charset=UTF-8
Cc: Peter Gutmann , "" 
Subject: Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 16:40:45 -0000

Hi Brian,

Thanks for clarifying, I now understand the use case you were
referring to. I especially missed case 1. I have further comments,
that I put inline.

On Mon, Dec 9, 2013 at 5:10 PM, Brian Smith  wrote:
> On Mon, Dec 9, 2013 at 7:23 AM, Alfredo Pironti  wrote:
>>> The case where the server does not use a certificate that the client
>>> would verify correctly as it would in the "normal" HTTPS case is not
>>> interesting. However, the case where opportunistic encryption is being
>>> used with a certificate that *is* valid (as defined by RFC5280, et
>>> al.) is interesting.
>>
>> I think this pre-condition makes your counter-example invalid.
>> A client that only accepts valid certificates is in practice only
>> implementing http2, not http2-tls-relaxed, in that client's behavior
>> doesn't change.
>
> Let's say the client is connecting to example.org:443 using TLS. There
> are two interesting possibilities:
>
> 1. The client could be resolving an http:// link that uses
> opportunistic encryption. In this case, if the client supports
> opportunistic encryption, the client would support "http2-tls-relaxed"
> and "http2-tls" (and "http1-tls") and a MitM attack, if attempted,
> would succeed.
>
> 2. The client could be resolving an https:// link. In this case, the
> client would only support "http2-tls" (and "http1-tls") and a MitM
> attack, if attempted, would fail in a end-user-notable way.
>
> With ALPN, it is trivial for the MitM to determine which case it is
> and act accordingly. With NPN, it is not trivial (it requires
> correlating data from multiple connections) and in many cases it may
> be impossible (e.g. when an HTTP cache has stored the response with
> the alternate-service upgrade header).

With ALPN, the client could always send both "http2-tls-relaxed" and
"http2", making its behavior indistinguishable in cases 1 and 2. Isn't
this enough to make your attacker desist?

For functionality, you may say that allowing "http2-tls-relaxed" in
case 2 may lead the server to send an invalid certificate when it
could have sent a valid one (and so one needs to distinguish the two
cases). Do we have a realistic scenario of this? I mean: a server that
prefers a "mitm-able" connection over a more secure one. A case where
the server would send a invalid certificate to disguise its identity
doesn't seem to work, because any further "http2"-only connection
(from any unauthenticated client) may reveal its identity anyway.

(I don't want to defend ALPN at all costs, but maybe what I propose is
enough to satisfy your use case? I'd prefer to conceal the upper
protocol from the attacker, but this has to be done at the same
security that other TLS-protected data get, and I find NPN does not
quite achieve this.)

Cheers,
Alfredo

>
>> Indeed, but under the assumption that only valid certificates are
>> accepted, the behaviors coincide to "http2".
>
> In the case of opportunistic encryption, we would support both valid
> and invalid certificates. In the case of normal "http2-tls" and
> "http1-tls", we would support only valid certificates.
>
> Cheers,
> Brian
>
>
> --
> Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

From watsonbladd@gmail.com  Mon Dec  9 09:00:02 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4C81AE38C for ; Mon,  9 Dec 2013 09:00:02 -0800 (PST)
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 8Ga1mZCD-I-c for ; Mon,  9 Dec 2013 09:00:01 -0800 (PST)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CDB8C1AE36D for ; Mon,  9 Dec 2013 09:00:00 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id q58so3659260wes.5 for ; Mon, 09 Dec 2013 08:59:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e5Li7gVCoE2ga0b4AAvNQ0E+m0rAX1t7xxj6qGKNGN4=; b=ZJNYN8pAfVhxO1T9TJeagjChRSQsoNUhUzDSqhK28W2TBIHSeOLzl1pmUSvqvXOacb gNwTrRNyTSmC+biV7K/CX3WqBtu3KSEjzKNmdGBHFuTH4c4tiYURqgd73YPogtEoUdt8 WA4jtCQf8TVn3GCTsqXGafuwRvCfsZypmn2vDDPNX29ySBkRN4OnzOdYPfTIZusPtWB/ MMqIwjYgN8y0apo6ukQ2I7TpP/hCBCSqV8WclBCDES7ZGLw/VPbK3regn8TvnuQ727N2 Tkz4m2UZbmtOORX/mgMsbJs2sX0YNvUYNzL5c3JedViLb72YgJZPmIdAb+bdztddu5X9 IbQQ==
MIME-Version: 1.0
X-Received: by 10.180.10.138 with SMTP id i10mr15226962wib.44.1386608395507; Mon, 09 Dec 2013 08:59:55 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 9 Dec 2013 08:59:55 -0800 (PST)
In-Reply-To: 
References: 
Date: Mon, 9 Dec 2013 08:59:55 -0800
Message-ID: 
From: Watson Ladd 
To: Brian Smith 
Content-Type: text/plain; charset=UTF-8
Cc: Peter Gutmann , "" 
Subject: Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 17:00:02 -0000

Why exactly does the client need to tell the server if it will
validate the cert or not?
Either the server has a cert that will validate, in which case it can
use it always, or not, in which case
there isn't a choice. Why signal to the world "I CAN BE FOOLED"?
Sincerely,
Watson Ladd

From stephen.farrell@cs.tcd.ie  Mon Dec  9 09:11:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D561ADFF4 for ; Mon,  9 Dec 2013 09:11:51 -0800 (PST)
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, RP_MATCHES_RCVD=-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 8e5m-pNu5XOM for ; Mon,  9 Dec 2013 09:11:46 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0311ADFE2 for ; Mon,  9 Dec 2013 09:11:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9A151BE51; Mon,  9 Dec 2013 17:11:40 +0000 (GMT)
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 ew6K4BC0ejhb; Mon,  9 Dec 2013 17:11:40 +0000 (GMT)
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 7418ABE50; Mon,  9 Dec 2013 17:11:40 +0000 (GMT)
Message-ID: <52A5F9CC.5090603@cs.tcd.ie>
Date: Mon, 09 Dec 2013 17:11:40 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Watson Ladd ,  Brian Smith 
References:  
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "" , Peter Gutmann 
Subject: Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 17:11:52 -0000

On 12/09/2013 04:59 PM, Watson Ladd wrote:
> Why exactly does the client need to tell the server if it will
> validate the cert or not?
> Either the server has a cert that will validate, in which case it can
> use it always, or not, in which case
> there isn't a choice. Why signal to the world "I CAN BE FOOLED"?

I'm not sure there's that much point in getting into
the specifics of Mark's scheme, since the httpbis wg
haven't decided to go down that road yet. (They might
but then they might do something else, who knows.)

For me (wearing no hats) it seems like standardising
NPN might take away energy from tls1.3 and/or slow
its deployment, which'd be a concern.

I'd also think that in the real case of ALPN and
HTTP/2.0 it'll be entirely obvious which protocol is
being negotiated just from the sizes of the packets
for any tls version <= 1.2 so any privacy loss or
gain is extremely minor to non-existent for now.
(That's because of HTTP/2.0 being binary etc.)

And I'd hope tls1.3 will be where we'd get significant
privacy gains in a more well thought out manner, e.g.
perhaps addressing the kind of application traffic
padding that Alfredo's draft described as a built-in
feature. (Or some equivalent.)

I've not thought through the negotiation thing though,
i.e. as to the impact of clients still having to be
able to do tls1.2 & ALPN for HTTP/2.0 even after tls1.3
is available on both ends. That does sound like its
worth thinking through but I'd hope could be handled
well in tls1.3 while still getting the privacy
benefits.

S.


From martin.thomson@gmail.com  Mon Dec  9 09:17:03 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA011AE36D for ; Mon,  9 Dec 2013 09:17:03 -0800 (PST)
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 nQkGHLWHm0Ek for ; Mon,  9 Dec 2013 09:17:01 -0800 (PST)
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 22FA61AE007 for ; Mon,  9 Dec 2013 09:17:00 -0800 (PST)
Received: by mail-wi0-f172.google.com with SMTP id en1so4134235wid.11 for ; Mon, 09 Dec 2013 09:16:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ztQQaNwVseXyb6VG4qUyeSY2tiz4Jeb/AWmDg+BykJo=; b=tUDCDA7jUAdwXsaHE5Yvf3QWWYDaq5KeZgXUlnEdw89NPFPXCoAzEkCePqUsODYx4G PjXmdMNmIR5h2AQ/fbwGJA450xCJ1op3Aznfd/ltOOdfYUfN5VWW/SJBnPinAjxijriY RoJtJIDW7MNxiaKk8KAH4+QTcKb804idbIrX2cGYZ7BRV9umMKA076lRjYVzFR+IlL9a KiHnuMZ0la2QHif90vD9tDjX3SCl7D4FYemZ8il2muqjQmSUH1iiOb997j3ZMXEDvta1 gkDGyds5ZWEjEgdXeaZGUrYIWpGTB0OSlA/efjo0FXDtUAD+qYLwpqlqljrLPSQRZ/Pi x0lw==
MIME-Version: 1.0
X-Received: by 10.194.175.133 with SMTP id ca5mr16622466wjc.19.1386609415536;  Mon, 09 Dec 2013 09:16:55 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Mon, 9 Dec 2013 09:16:55 -0800 (PST)
In-Reply-To: 
References: 
Date: Mon, 9 Dec 2013 09:16:55 -0800
Message-ID: 
From: Martin Thomson 
To: Brian Smith 
Content-Type: text/plain; charset=UTF-8
Cc: Peter Gutmann , "" 
Subject: Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 17:17:04 -0000

On 9 December 2013 05:56, Brian Smith  wrote:
> Please see http://tools.ietf.org/html/draft-nottingham-http2-encryption-01#section-2.1
> (read the whole document, but section 2.1 is especially interesting).
> That document defines a mechanism wherein, through protocol
> negotiation, a web browser and server can agree on a "relaxed" form of
> TLS for HTTP where the client does not authenticate the server's
> certificate. The goal is to enable a form of opportunistic encryption
> to HTTP.

My feedback to Mark on this point was that this negotiation was
completely unnecessary.

A server already has a way to signal that it doesn't care about
certain security properties of a resource.  It does that by omitting
the 's' in the resource URL.

A client is then left to decide whether it cares about those
properties.  What requirements are then placed on the subsequent
interactions are up to the client.

From nick.a.mathewson@gmail.com  Mon Dec  9 10:49:22 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A211AE3DE for ; Mon,  9 Dec 2013 10:49:22 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 PnwcAdn_LmTY for ; Mon,  9 Dec 2013 10:49:20 -0800 (PST)
Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AA3721AE04B for ; Mon,  9 Dec 2013 10:49:20 -0800 (PST)
Received: by mail-qc0-f172.google.com with SMTP id e16so3050820qcx.31 for ; Mon, 09 Dec 2013 10:49:15 -0800 (PST)
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=i7motttgY8VTOBpCHJnSMF/IaVbJb3VUWoNZFAHk1p8=; b=yyeOAH/p7enW8KOlKnvuBT0IBEsvMmnqaco7QZZFblGAwLYM9/l4FVBx5ZBH9WKxqt vlRsLjcchH9SqekugqBbcK7qqZBMTCqyP+qVSRbAnpnCl5ZLm8N6HoO8wQaQO6B6Fxyp 6mFLhZeL4TBXkboa2nPNCDP3IKbeTKx/gWqTDCO0MziGsegLgJCyOBPIjqglxGpN5Gsu 6siltaWFXjJdHZwOXoBEYv28hYotPNI3XaIB1fyhovIUKAz1xgA1elIXxAElNXenWYsF ix9k9msWufJSQrpqxSCmf8UfAwt7U/h6mY78Sqbwg+UkI3PDidZQQIkGKNrdUJB1PKS+ tXFg==
MIME-Version: 1.0
X-Received: by 10.49.35.52 with SMTP id e20mr186051452qej.63.1386614955680; Mon, 09 Dec 2013 10:49:15 -0800 (PST)
Sender: nick.a.mathewson@gmail.com
Received: by 10.140.102.82 with HTTP; Mon, 9 Dec 2013 10:49:15 -0800 (PST)
In-Reply-To: 
References:  
Date: Mon, 9 Dec 2013 13:49:15 -0500
X-Google-Sender-Auth: 6IPXFbRb3OFYRZJ_wbr81euzEKA
Message-ID: 
From: Nick Mathewson 
To: Wan-Teh Chang 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 18:49:22 -0000

On Fri, Dec 6, 2013 at 2:59 PM, Wan-Teh Chang  wrote:
> Sorry about my late reply. I am a programmer working on the NSS crypto
> libraries. While reviewing recent changes to NSS, I noticed that
> Nick's proposal 1 has been implemented in the OpenSSL and NSS source
> code repositories, which led me to this old email thread.
>
> The only protocol feature I know of that uses the gmt_unix_time field
> of ClientHello.random is Adam Langley's TLS Snap Start Internet-Draft
> [1]. See Section 3 of Adam's draft. This method is one of the
> anti-reply mechanisms being considered in Eric Rescorla's TLS 1.3 new
> handshake flows Internet-Draft [2], and is being used in the QUIC
> protocol.
>
> So, I'd like to offer another proposal:
>
> PROPOSAL 4:
>
> Add a random clock skew to the current time. For example, generate a
> random signed integer in the interval [-512, 511] (inclusive) and add
> it to the return value of time(). This adds roughly a +/-8.5 minutes
> skew to the current time.
>
> If this proposal is an acceptable solution to the client
> fingerprinting problem, then gmt_unix_time in ClientHello.random will
> remain viable as part of an anti-reply mechanism for TLS 1.3 new
> handshake flows.

Hello, and thanks for thinking about this!

I'd suggest that this approach should be considered only with caution,
and used only when absolutely necessary (in other words, when 0-RTT
truly is in use).  If it can be avoided entirely, as with Brian
Smith's idea, it's probably better to do so.  If the timestamp can be
removed from the Random and added as encrypted data to a proposed
snap-start extension somehow, that's also an improvement, though an
imperfect one.

Random skew helps only a little:
   * It does nothing to conceal large drifts, which seem to be fairly
common in practice.  If two clients have drifted more than 1024
seconds apart, they'll remain completely partitioned.
   * Given multiple observations from the same client, it's trivial to
recover a good estimate of the client's clock skew and use that to
link other observations probabilistically to the same client.

On the latter point, I'd suggest that rounding is a little better than
adding random skew, since only a smaller fraction of a client's
declared times will leak anything about the client's skew.
Randomize-and-round might be better still, though I'm afraid I haven't
worked through the full analysis.

(As a reminder, using the time to avoid snap-start replays would be a
_new_ purpose for gmt_unix_time .  As discussed earlier in this thread
and in http://datatracker.ietf.org/doc/draft-mathewson-no-gmtunixtime/
, the gmt_unix_time is neither necessary nor sufficient for its
current declared purposes.)

peace,
-- 
Nick Mathewson

From nick.a.mathewson@gmail.com  Mon Dec  9 11:04:43 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDFE1AE4AD for ; Mon,  9 Dec 2013 11:04:43 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 XgFlXFy8KXuy for ; Mon,  9 Dec 2013 11:04:42 -0800 (PST)
Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 17A7B1AE4AB for ; Mon,  9 Dec 2013 11:04:41 -0800 (PST)
Received: by mail-qa0-f50.google.com with SMTP id i13so2951060qae.9 for ; Mon, 09 Dec 2013 11:04:37 -0800 (PST)
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=juyj+WNuwCvlL80L/bmruS3aDVp9SH1WSUmXqv6Wf9k=; b=yfLcrvogy/LSyGe2pdFJqYXQI4AAwRT5wbrYIiG+IjqaX8WiAF0Xz5sTtoznvaiKp6 w+AoCRT8G1rsSa6pqvLTckSwscSTpO8+uiNf8+/G2Nj+ZVr17QoYcMbFBBXbJM1VfHdi 180gsdMhScNR/Q0SvAoinxzUR5C7QevgfLL/fNe+yTzX1a7PdQv6XU2gwU/V/shruN3U aEMLCM6dqlDt+QY2mBo25yJNrl8fMDoQDG3hYqSXkMxE0aCy1rUwRJCRXggkVwVbvIGK jcny68tqCBB9WPGjJmEx3UA1YvcG7mMj6HFc0DJwht1+BOD6CZM3uFM4tYKCH7lgHQJT GzWQ==
MIME-Version: 1.0
X-Received: by 10.229.140.129 with SMTP id i1mr35618656qcu.13.1386615876977; Mon, 09 Dec 2013 11:04:36 -0800 (PST)
Sender: nick.a.mathewson@gmail.com
Received: by 10.140.102.82 with HTTP; Mon, 9 Dec 2013 11:04:36 -0800 (PST)
In-Reply-To: 
References:   
Date: Mon, 9 Dec 2013 14:04:36 -0500
X-Google-Sender-Auth: eVZ6lnYRcIPwc9-veDjBiKGOhwI
Message-ID: 
From: Nick Mathewson 
To: Brian Smith 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 19:04:43 -0000

On Fri, Dec 6, 2013 at 3:14 PM, Brian Smith  wrote:
> On Fri, Dec 6, 2013 at 11:59 AM, Wan-Teh Chang  wrote:
>> PROPOSAL 4:
>>
>> Add a random clock skew to the current time. For example, generate a
>> random signed integer in the interval [-512, 511] (inclusive) and add
>> it to the return value of time(). This adds roughly a +/-8.5 minutes
>> skew to the current time.
>
> When the server tells the client that it supports the 0-RTT handshake
> scheme, can't the server also tell the client what time the server
> things it is? Then the client could calculate the offset between its
> local perception of the time and the server's perception of the time,
> and apply that offset to whatever timestamp it sends in its 0-RTT
> handshake.

This is a neat idea, and much more effective at randomization than at
hiding the client's view of the current time.

I believe that the QUIC crypto spec mentioned a similar idea (but
dismissed it in favor of another solution): "The first of these issues
could be addressed by having the clients take a clock-sync signal from
the server and define a =93server local time=94 offset for that server."

One caveat here is that a server could tell different clients that it
had different skew values, thereby creating yet another way to set
stealth cookies.  You'd need to be sure not to share your view of
server-local time across anonymous sessions, while roaming in a
privacy-conscious way, and so on.

> Also, timestamps is only needed for the 0-RTT handshake, handshakes
> that aren't attempting to be 0-RTT shouldn't include a timestamp. So,
> the timestamps should probably be moved to the extension that
> negotiates the 0-RTT handshake. That way, the fingerprinting risk,
> whatever it is, is limited to applications that are actually trying to
> use that feature, and applications/servers that are especially
> sensitive to fingerprinting (e.g. the Tor Browser) may cleanly avoid
> the issue by disabling 0-RTT handshake support, as a worst-case
> option.

I'd agree that this is an improvement over sending gmt_unix_time to
everybody indiscriminately, surely, though you would (as Wan-Teh Chang
notes) need to change the inputs to the KDF a bit.  It doesn't seem
like an insurmountable obstacle by any means, though.

best wishes,
--=20
Nick Mathewson

From trevp@trevp.net  Mon Dec  9 11:41:21 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004211AE4E8 for ; Mon,  9 Dec 2013 11:41:20 -0800 (PST)
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=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 6f6lIp5HBAiZ for ; Mon,  9 Dec 2013 11:41:14 -0800 (PST)
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF941AE3F3 for ; Mon,  9 Dec 2013 11:41:14 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id a1so3965100wgh.5 for ; Mon, 09 Dec 2013 11:41:08 -0800 (PST)
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=p1b1KlRyLDRtFoR+IFlFwFDdA9vX73FjFY0IAFhcgwc=; b=epkKknDMYRJkgdohP4XCFONMQicI8PPRRGP1zGQ4oTTD96dqyUpnzmIhrEHF/oHxaN gIfUBH3U8UDohDP/QtU5NX948+PNROf+g0QRZtINeBpazOeVonWyAZmY4sl5OlAEBdLR OZDLRtrlW+tlzRGu7dZSuwD/txaKbwaOvrBu1bCeW7aQnfJmn2Fa/Td5WAJESZynOspB yz9B2kgmXz64JXykIt2+PMOPUE2MOQKD75zRTlSdLTzORcOnRkGMtA2qSJkGFPC2Dd1k RCmYZ7OsIwTEV0cPVGZD89KBwA0SR2X6nd6IJmOPQ5ZUllj7RI1d4nW/IOBSinCHD1Gp 6fjA==
X-Gm-Message-State: ALoCoQkUahpwbd3j1qUawWViKKGXvOyC1fyy1Mv/eQcglw14d31RCQrBZb20C/TE7fU8XPBdasX0
MIME-Version: 1.0
X-Received: by 10.194.104.42 with SMTP id gb10mr17225084wjb.16.1386618068827;  Mon, 09 Dec 2013 11:41:08 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Mon, 9 Dec 2013 11:41:08 -0800 (PST)
X-Originating-IP: [12.27.66.5]
In-Reply-To: 
References: <20130906074540.19067.67943.idtracker@ietfa.amsl.com>  
Date: Mon, 9 Dec 2013 11:41:08 -0800
Message-ID: 
From: Trevor Perrin 
To: SeongHan Shin 
Content-Type: text/plain; charset=ISO-8859-1
Cc: =?UTF-8?B?5Y+k5Y6f5ZKM6YKm?= , cfrg@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] I-D Action: draft-irtf-cfrg-augpake-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: Mon, 09 Dec 2013 19:41:21 -0000

Hi Shin,

Just to be clear - I was making fun of Kevin Igoe, not yourself -
AugPAKE seems like a great piece of work.

Couple questions:

 - There's obvious similarities with SRP.  Do you think the AugPAKE
proof techniques could be used to make a security proof for SRP?  (For
an elliptic curve SRP, you could imagine using the SRP verifier with
Elligator to encrypt the g^b value, instead of SRP's traditional "B =
kv + g^b").

 - There seems to be an ordering constraint between AugPAKE's client
and server messages, requiring the client to go first.  For TLS at
least, such a constraint is awkward.  It either requires an extra
round-trip for the server to communicate the salt and group values, or
requires the client to assume the group and use no salt (the approach
taken in your TLS draft [1]).  The latest version of SRP [2] was able
to remove this constraint.  Is it possible to do the same for AugPAKE?


Trevor


[1] http://tools.ietf.org/html/draft-shin-tls-augpake-01

[2]
 http://tools.ietf.org/html/rfc5054
 http://srp.stanford.edu/design.html
 http://srp.stanford.edu/srp6.ps


On Fri, Dec 6, 2013 at 12:26 PM, Trevor Perrin  wrote:
> I really like this idea & can find no problems.
>
> Since a single cursory opinion counts for CFRG consensus [1,2],
> consider this approved by CFRG and our NSA overseers.
>
> Thanks, come again!
>
>
> Trevor
>
>
> P.S. The treatment of random numbers could be improved, consider
> referencing NIST SP 800-90A.
>
> (psst Kevin ^^^ THIS is how it's done.  *FINESSE*, or you'll never
> work the big leagues!)
>
>
> [1] http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html
> [2] http://www.ietf.org/proceedings/84/minutes/minutes-84-tls
>
>
> On Sun, Sep 29, 2013 at 11:18 PM, SeongHan Shin
>  wrote:
>> Dear all,
>>
>> We submitted our I-D regarding augmented PAKE
>> that provides extra protection to server compromise compared to balanced
>> PAKE.
>> (Of course, it can be easily converted to the balanced one)
>>
>> Any comments are welcome!
>>
>> Best regards,
>> Shin
>>
>>
>> On Fri, Sep 6, 2013 at 4:45 PM,  wrote:
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>  This draft is a work item of the Crypto Forum Research Group Working
>>> Group of the IETF.
>>>
>>>         Title           : Augmented Password-Authenticated Key Exchange
>>> (AugPAKE)
>>>         Author(s)       : SeongHan Shin
>>>                           Kazukuni Kobara
>>>         Filename        : draft-irtf-cfrg-augpake-00.txt
>>>         Pages           : 17
>>>         Date            : 2013-09-06
>>>
>>> Abstract:
>>>    This document describes a secure and highly-efficient augmented
>>>    password-authenticated key exchange (AugPAKE) protocol where a user
>>>    remembers a low-entropy password and its verifier is registered in
>>>    the intended server.  In general, the user password is chosen from a
>>>    small set of dictionary whose space is within the off-line dictionary
>>>    attacks.  The AugPAKE protocol described here is secure against
>>>    passive attacks, active attacks and off-line dictionary attacks (on
>>>    the obtained messages with passive/active attacks).  Also, this
>>>    protocol provides resistance to server compromise in the context that
>>>    an attacker, who obtained the password verifier from the server, must
>>>    at least perform off-line dictionary attacks to gain any advantage in
>>>    impersonating the user.  The AugPAKE protocol is not only provably
>>>    secure in the random oracle model but also the most efficient over
>>>    the previous augmented PAKE protocols (SRP and AMP).
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-irtf-cfrg-augpake
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-irtf-cfrg-augpake-00
>>>
>>>
>>> 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/
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> Cfrg@irtf.org
>>> http://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>>
>>
>> --
>> ------------------------------------------------------------------
>> SeongHan Shin
>> Research Institute for Secure Systems (RISEC),
>> National Institute of Advanced Industrial Science and Technology (AIST),
>> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
>> Tel : +81-29-861-2670/5284
>> Fax : +81-29-861-5285
>> E-mail : seonghan.shin@aist.go.jp
>> ------------------------------------------------------------------
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
>>

From martin.thomson@gmail.com  Mon Dec  9 11:54:21 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12031AE50F for ; Mon,  9 Dec 2013 11:54:20 -0800 (PST)
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 B5hYI0Go5gHa for ; Mon,  9 Dec 2013 11:54:18 -0800 (PST)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 969CD1AE07F for ; Mon,  9 Dec 2013 11:54:18 -0800 (PST)
Received: by mail-we0-f181.google.com with SMTP id x55so3922125wes.40 for ; Mon, 09 Dec 2013 11:54:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=emw2FRBHcfdKWnWq8uk4wRnKdjhOBtU5S8jr0pJK+fA=; b=CsnYdTQnXJVavQ18s5DQvDaOER/KirLXzrVJz4c4f0qHjUtNn3khvGp9Rvb/a/+Z7/ BM3WrIZ9ufQj7FIAXmvL6R+1+dlDpS5tI/iz8K+7+aDCTVVtKV25g0jGP//QX6fgA8OB hxFUCYbQkK4y5A8cRbDoRwFpi4BVmnohyWZ7o1Sw3xGxmipKG9bd2N6CJmz9masu8C58 yBgEDOZ5vVE0HYk1xIZ0+XX4P5RX9JKsCbd9K2HyF8+PnEOfWdl9cg56lTJhuYi775k3 tcoIO0BOkzZna9WlPquFDSPcnqLLLxs7FAff9+wbkdCruFFCzz0OodR7OjpmlR6+YqLU LzCw==
MIME-Version: 1.0
X-Received: by 10.180.101.230 with SMTP id fj6mr15670990wib.58.1386618853274;  Mon, 09 Dec 2013 11:54:13 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Mon, 9 Dec 2013 11:54:13 -0800 (PST)
In-Reply-To: 
References:   
Date: Mon, 9 Dec 2013 11:54:13 -0800
Message-ID: 
From: Martin Thomson 
To: Nick Mathewson 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 19:54:21 -0000

On 9 December 2013 10:49, Nick Mathewson  wrote:
> On the latter point, I'd suggest that rounding is a little better than
> adding random skew, since only a smaller fraction of a client's
> declared times will leak anything about the client's skew.
> Randomize-and-round might be better still, though I'm afraid I haven't
> worked through the full analysis.

It depends on what you believe you are protecting against, but if you
intend to protect against revealing the value of the local clock, then
neither is sufficient.  It all depends on how many samples your
adversary has available.

With rounding, all you need to recover the time is to watch for edge
crossings and align them.  With randomization, you ultimately reveal
time by hitting the limits of the random space.  9 bits of space
doesn't require a lot of samples.

If you want to do a really good job, then a 1-dimensional application
of the methods described in
http://tools.ietf.org/html/draft-thomson-geopriv-location-obscuring-01
would most likely work.  I'd probably go with full random before I
went there though - maintaining more secrets sounds like a good way to
get in trouble.

From Andrei.Popov@microsoft.com  Mon Dec  9 12:25:43 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2171AE07A for ; Mon,  9 Dec 2013 12:25:43 -0800 (PST)
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 xLWu9v7zMcwc for ; Mon,  9 Dec 2013 12:25:39 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id A44721AE2B4 for ; Mon,  9 Dec 2013 12:25:39 -0800 (PST)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) with Microsoft SMTP Server (TLS) id 15.0.837.10; Mon, 9 Dec 2013 20:25:33 +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.0837.004; Mon, 9 Dec 2013 20:25:33 +0000
From: Andrei Popov 
To: Brian Smith 
Thread-Topic: [TLS] ALPN concerns
Thread-Index: Ac7avMo2EJNfUuzvrkqBLee9/27ncAAXTtmAAnSaQgAAG44eMAPiIJSAAA2U/GA=
Date: Mon, 9 Dec 2013 20:25:32 +0000
Message-ID: <1a15057e208b42709bcfb3c6c233cebb@BL2PR03MB419.namprd03.prod.outlook.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>    
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::3]
x-forefront-prvs: 00550ABE1F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(199002)(189002)(377454003)(51444003)(13464003)(52604005)(51704005)(24454002)(77982001)(51856001)(59766001)(47976001)(50986001)(81816001)(65816001)(74876001)(74706001)(80022001)(54356001)(54316002)(56776001)(53806001)(31966008)(74662001)(74502001)(81686001)(47446002)(63696002)(81342001)(56816005)(76482001)(85306002)(80976001)(76796001)(76786001)(33646001)(83322001)(19580395003)(69226001)(87936001)(74316001)(2656002)(76576001)(49866001)(4396001)(46102001)(90146001)(81542001)(47736001)(79102001)(87266001)(19580405001)(85852003)(83072002)(74366001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB419; H:BL2PR03MB419.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::3; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "" , Peter Gutmann 
Subject: Re: [TLS] ALPN concerns
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 20:25:43 -0000

SGkgQnJpYW4sDQoNClRoYW5rcyBmb3IgZGVzY3JpYmluZyB5b3VyIGlkZWFzIGZvciBlYXJseSBl
bmNyeXB0aW9uIGluIHRoZSBUTFMgaGFuZHNoYWtlLiBBdCBhIGhpZ2ggbGV2ZWwsIHRoaXMgbG9v
a3MgdmVyeSBzaW1pbGFyIHRvIHNvbWUgb2YgdGhlIGZsb3dzIGluIEVyaWMgUmVzY29ybGEncyBU
TFMgMS4zIGRyYWZ0LiBQZXJoYXBzIHdoYXQgd2UgbmVlZCBpcyB0byBjb252ZXJnZSBvbiB0aGUg
bmV4dCBsZXZlbCBvZiBkZXRhaWwsIGFuZCBJIGJlbGlldmUgRXJpYyB3aWxsIHdlbGNvbWUgeW91
ciBzdWdnZXN0aW9uc1xmZWVkYmFjayBhcyBoZSBpcyB3b3JraW5nIG9uIGFuIHVwZGF0ZWQgZHJh
ZnQuDQoNCkkgYWdyZWUgdGhhdCBUTFMgMS4zIGRlcGxveW1lbnQgd2lsbCBiZSBhIGNoYWxsZW5n
ZSwgYnV0IEkgZG9uJ3QgYmVsaWV2ZSBBTFBOIHZzLiBOUE4gd2lsbCBtYWtlIGl0IGFueSBoYXJk
ZXIgb3IgZWFzaWVyLiBFaXRoZXIgdGhlIHNlcnZlciB3aWxsIHN1cHBvcnQgdGhlIFRMUyAxLjMg
cHJvdG9jb2wsIHdpdGggaXRzIGVuY3J5cHRlZCBleHRlbnNpb25zIGFuZCBhcHBsaWNhdGlvbiBw
cm90b2NvbCBuZWdvdGlhdGlvbiBtZWNoYW5pc20sIG9yIGEgZmFsbGJhY2sgdG8gVExTIDEuMi8x
LjEvMS4wIHdpbGwgbmVlZCB0byB0YWtlIHBsYWNlLCBhdCB3aGljaCBwb2ludCB0aGUgY3VycmVu
dCBjbGVhci10ZXh0IGV4dGVuc2lvbnMgd2lsbCBuZWVkIHRvIGJlIHNlbnQuDQoNCkNoZWVycywN
Cg0KQW5kcmVpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcmlhbiBTbWl0
aCBbbWFpbHRvOmJyaWFuQGJyaWFuc21pdGgub3JnXSANClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIg
OSwgMjAxMyA1OjMzIEFNDQpUbzogQW5kcmVpIFBvcG92DQpDYzogPHRsc0BpZXRmLm9yZz47IFBl
dGVyIEd1dG1hbm4NClN1YmplY3Q6IFJlOiBbVExTXSBBTFBOIGNvbmNlcm5zDQoNCkhpIEFuZHJl
aSwNCg0KU29ycnkgZm9yIHRoZSBkZWxheS4gUGxlYXNlIHNlZSByZXBsaWVzIGlubGluZS4NCg0K
T24gVHVlLCBOb3YgMTksIDIwMTMgYXQgMTE6NDIgQU0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBv
cG92QG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPiBJIHRvdGFsbHkgYWdyZWUgdGhhdCB3ZSBuZWVk
IHRvIGVuY3J5cHQgbW9yZSBpbmZvcm1hdGlvbiBpbiB0aGUgVExTIA0KPiBoYW5kc2hha2UsIGlu
Y2x1ZGluZyB0aGUgY2xpZW50IGNlcnQgYW5kIHRoZSBjb250ZW50cyBvZiB2YXJpb3VzIGV4dGVu
c2lvbnMsIHN1Y2ggYXMgU05JIGFuZCBBTFBOLg0KPiBVbmZvcnR1bmF0ZWx5LCB0aGUgb25seSB3
YXkgdG8gbWFrZSB0aGlzIGluZm9ybWF0aW9uIGNvbmZpZGVudGlhbCBpbiANCj4gdGhlIGV4aXN0
aW5nIHZlcnNpb25zIG9mIFRMUyBpcyB0byBpbmN1ciBhZGRpdGlvbmFsIHJvdW5kLXRyaXBzIChi
eSANCj4gdXNpbmcgcmVuZWdvdGlhdGlvbiwgb3Igb3RoZXJ3aXNlIGV4Y2hhbmdpbmcgbWVzc2Fn
ZXMgYWZ0ZXIgdGhlIFRMUyANCj4gaGFuZHNoYWtlIGlzIGNvbXBsZXRlKS4gVGhpcyBpcyBvbmUg
b2YgdGhlIHJlYXNvbnMgd2h5IHRoZSBUTFMgV0cgaXMgcHVzaGluZyBoYXJkIHRvIG1ha2UgcHJv
Z3Jlc3Mgb24gVExTMS4zLg0KDQpVbmZvcnR1bmF0ZWx5LCBsaWtlIEkgc2FpZCBpbiBteSBwcmV2
aW91cyBtZXNzYWdlLCBJIHRoaW5rIGl0IHdpbGwgYmUgZXh0cmVtZWx5IGRpZmZpY3VsdCwgYW5k
IHByb2JhYmx5IGltcG9zc2libGUsIGZvciB1cyB0byBlbmNyeXB0IHRoZSBBTFBOIChhbmQgU05J
KSBwYXJ0IG9mIHRoZSBoYW5kc2hha2UgaW4gVExTIDEuMyBpZiB3ZSBzdGFuZGFyZGl6ZSBhbmQg
ZGVwbG95IHRoZSBjdXJyZW50IEFMUE4gZGVzaWduLiBBcyBzb29uIGFzIHdlIHN0YXJ0IHVzaW5n
IGl0LCB3ZWIgYnJvd3NlcnMgd2lsbCBoYXZlIGEgY29tcGF0aWJpbGl0eSBidXJkZW4gdG8gY29u
dGludWUgc2VuZGluZyB0aGUgdW5lbmNyeXB0ZWQgQUxQTiBoZWFkZXIgaW4gdGhlaXIgQ2xpZW50
SGVsbG8sIGJlY2F1c2Ugd2Ugd29uJ3QgYmUgYWJsZSB0byBhc3N1bWUgdGhhdCB0aGUgc2VydmVy
IHN1cHBvcnRzIFRMUyAxLjMncyBlbmNyeXB0ZWQgQUxQTi4NCg0KTm90ZSB0aGF0IHRoaXMgaXMg
bm90IGEgcHJvYmxlbSBmb3IgTlBOIGJlY2F1c2UgTlBOIGRvZXMgbm90IGRpc2Nsb3NlIGFueSBp
bmZvcm1hdGlvbiBpbiB0aGUgQ2xpZW50SGVsbG8uIFdlIGNhbiBjb21wbGV0ZWx5IGNoYW5nZSBo
b3cgcHJvdG9jb2wgbmVnb3RpYXRpb24gd29ya3MgaW4gVExTIDEuMywgYW5kIGNsaWVudHMgdGhh
dCBzdXBwb3J0IE5QTiBjb3VsZCBzZWVtbGVzc2x5IHRyYW5zaXRpb24gdG8gdGhlIG5ldyBtZWNo
YW5pc20gd2l0aG91dCByaXNraW5nIGFueSBuZWdhdGl2ZSBjb21wYXRpYmlsaXR5IG9yIHBlcmZv
cm1hbmNlIGltcGFjdC4NCg0KPj4gQXMgZmFyIGFzIEkndmUgYmVlbiBsZWQgdG8gYmVsaWV2ZSwg
QUxQTiBleGlzdHMgcHJpbWFyaWx5IHRvIGFsbG93IA0KPj4gTWl0TSB0byBtb3JlIGVhc2lseSBp
bnNwZWN0IHdoYXQgcHJvdG9jb2wgdGhlIGFwcGxpY2F0aW9uIGlzIHNwZWFraW5nIA0KPj4gYW5k
IHBvc3NpYmx5IGJsb2NrIHRoZSBhcHBsaWNhdGlvbiwgd2l0aCBhcyBsb3cgb2YgYSBjb3N0IHRv
IHRoZSBNaXRNIA0KPj4gYXMgcG9zc2libGUtLWkuZS4gZXhhY3RseSB0aGUgb3Bwb3NpdGUgZ29h
bCBvZiBldmVyeXRoaW5nIHdlIGRpc2N1c3NlZCBhdCBJRVRGODggaW4gcGVycGFzcyBhbmQgaW4g
b3RoZXIgZGlzY3Vzc2lvbnMuDQo+DQo+IE5vLCBBTFBOIGV4aXN0cyBwcmltYXJpbHkgdG8gbmVn
b3RpYXRlIGFuIGFwcGxpY2F0aW9uIHByb3RvY29sIHdpdGhvdXQgDQo+IGluY3VycmluZyBleHRy
YSByb3VuZC10cmlwcywgdG8gYWxsb3cgdGhlIHNlcnZlciB0byBwaWNrIHRoZSANCj4gYXBwbGlj
YXRpb24gcHJvdG9jb2wgYW5kIHByZXNlbnQgdGhlIGNvcnJlc3BvbmRpbmcgaWRlbnRpdHksIGFu
ZCB0byBhbGlnbiB3aXRoIHRoZSBleGlzdGluZyBUTFMgZXh0ZW5zaW9ucy4NCg0KSSBoYXZlIGRp
c2N1c3NlZCB0aGUgQUxQTiB2cyBOUE4gaXNzdWUgd2l0aCBFcmljIFJlc2NvcmxhIChjby1jaGFp
ciBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAsIGFsb25nc2lkZSBKb3NlcGggU2Fsb3dleSBmcm9tIENp
c2NvKSBtdWx0aXBsZSB0aW1lcywgYW5kIGVhY2ggdGltZSBFcmljIHNhaWQgdGhhdCBhbGxvd2lu
ZyBwYXNzaXZlIE1pdE0gZGV2aWNlcyB0byBrbm93IHdoaWNoIHByb3RvY29sIGlzIGJlaW5nIHVz
ZWQgaXMgaW1wb3J0YW50LCBhbmQgdGhhdCB0aGlzIGlzIGFuIGFkdmFudGFnZSBmb3IgQUxQTiBv
dmVyIE5QTi4gSSB3aWxsIGxldCBoaW0gZXhwbGFpbiB3aHksIGlmIGl0IGhhc24ndCBhbHJlYWR5
IGJlZW4gZXhwbGFpbmVkIG9uIHRoZSBsaXN0LiBGV0lXLCBJIHN0cm9uZ2x5IGRpc2FncmVlIHRo
YXQgaXQgc2hvdWxkIGJlIGEgZ29hbCB0byBhbGxvdyBwYXNzaXZlIE1pdE0gdG8ga25vdyB3aGlj
aCBwcm90b2NvbCBpcyBiZWluZyB1c2VkLiBJbiBmYWN0LCBJIHRoaW5rIHRoYXQgd2Ugc2hvdWxk
IGhhdmUgYSBnb2FsIG9mIHByb3RlY3RpbmcgdGhlIHByb3RvY29sIGluZm9ybWF0aW9uIHNvIHRo
YXQgcGFzc2l2ZSBNaXRNIGhhcyBhIG11Y2ggbW9yZSBkaWZmaWN1bHQgdGltZSBvZiBkZXRlcm1p
bmluZyB3aXRoIGNlcnRhaW50eSB0aGUgcHJvdG9jb2wgYmVpbmcgdXNlZC4NCg0KPj5JIHRoaW5r
IHRoYXQgaW4gbWFueSBjYXNlcywgdHJhZmZpYyBhbmFseXNpcyB0aGF0IHJlbGllcyBvbiB0aW1p
bmcgDQo+PmluZm9ybWF0aW9uIHdpbGwgYmUgYWJsZSB0byB0ZWxsIHdpdGggYSBoaWdoIGRlZ3Jl
ZSBvZiBhY2N1cmFjeSB3aGljaCANCj4+cHJvdG9jb2wgaGFzIGJlZW4gc2VsZWN0ZWQgZm9yIHVz
ZSBvbiB0aGUgY29ubmVjdGlvbi4gSG93ZXZlciwgdHJhZmZpYyANCj4+YW5hbHlzaXMgY2Fubm90
IHRlbGwgdXMgd2hhdCBwcm90b2NvbHMgd2VyZSAgb2ZmZXJlZCBidXQgKm5vdCogc2VsZWN0ZWQu
DQo+DQo+IENvcnJlY3QsIGFuZCBOUE4gb2ZmZXJzIHRoZSBsaXN0IG9mIHRoZSBhcHBsaWNhdGlv
biBwcm90b2NvbHMgaW4gDQo+IGNsZWFyLXRleHQsIHNvIGl0IGRvZXMgbm90IHNvbHZlIHRoaXMg
cHJvYmxlbS4NCg0KTlBOIGRvZXMgc29sdmUgdGhpcyBwcm9ibGVtICpmb3IgdGhlIGNsaWVudCou
IE5QTiBkb2VzIG5vdCBzb2x2ZSB0aGUgcHJvYmxlbSBmb3IgdGhlIHNlcnZlci4gSG93ZXZlciwg
aW4gdGhlIGNvbnRleHQgb2Ygd2ViIGJyb3dzZXJzIGRvaW5nIG5vcm1hbCB3ZWIgYnJvd3Npbmcg
c3R1ZmYgKGFzIG9wcG9zZWQgdG8gRFRMUyBpbiBXZWJSVEMpLCB0aGUgY2xpZW50J3MgcHJpdmFj
eSBpcyBmdW5kYW1lbnRhbGx5IG1vcmUgaW1wb3J0YW50IHRoYW4gdGhlIHNlcnZlcidzIHByaXZh
Y3kgaW4gdGhpcyByZXNwZWN0LiBBZGRpdGlvbmFsbHksIGlmIHlvdSBoYXZlIGEgcHVibGljbHkt
YWNjZXNzaWJsZSBzZXJ2ZXIgb24gdGhlIGludGVybmV0LCBwZW9wbGUgY291bGQgYWx3YXlzIHBy
b2JlIGl0ICh3aXRoIGVpdGhlciBBTFBOIG9yDQpOUE4pIHRvIGRldGVybWluZSB3aGljaCBwcm90
b2NvbHMsIHdoaWNoIHZlcnNpb25zIG9mIHByb3RvY29scywgYW5kIGxpa2VseSB3aGljaCBpbXBs
ZW1lbnRhdGlvbnMgb2YgdGhvc2UgcHJvdG9jb2xzIGFyZSBhdmFpbGFibGUsIHNvIHByb3RlY3Rp
bmcgdGhlIHNlcnZlcidzIHByaXZhY3kgaW4gdGhpcyByZWdhcmQgaXMgZnV0aWxlLiBDb252ZXJz
ZWx5LCBwcm90ZWN0aW5nIHRoZSBjbGllbnQncyBwcml2YWN5IGlzIG11Y2ggbW9yZSBwcmFjdGlj
YWwgYW5kIHVzZWZ1bC4gV2UgaGF2ZSBzZWVuLCBmb3IgZXhhbXBsZSwgaG93IHRoZSBUb3IgcHJv
dG9jb2wgYXR0ZW1wdHMgdG8gbWFrZSBpdHMgVExTIGhhbmRzaGFrZSBsb29rIGxpa2UgYSBicm93
c2VyJ3MgaGFuZHNoYWtlcyBpbiBvcmRlciB0byB0aHdhcnQgYmxvY2tpbmcgZmlsdGVyaW5nIG9m
IHRoZSBUb3IgcHJvdG9jb2wuDQoNCj4gSWYgd2UgY2FuIGF2b2lkIGFwcGxpY2F0aW9uIHByb3Rv
Y29sIG5lZ290aWF0aW9uIGF0IHRoZSBUTFMgbGF5ZXIgd2l0aG91dCBpbmN1cnJpbmcgYWRkaXRp
b25hbCByb3VuZC10cmlwcywgSSBhbSBpbiBmdWxsIHN1cHBvcnQuIExvb2tpbmcgZm9yd2FyZCB0
byB0aGUgd3JpdGUtdXAuDQoNCkkgYW0gc29ycnkgdGhhdCBJJ3ZlIHlldCB0byBjcmVhdGUgYW4g
aW50ZXJuZXQgZHJhZnQgZGVzY3JpYmluZyB0aGUgaWRlYS4gSG93ZXZlciwgaG9wZWZ1bGx5IHRo
ZSBmb2xsb3dpbmcgZGVzY3JpcHRpb24sIHdoaWNoIGlzIGNvcHktcGFzdGVkIGZyb20gYSBwcml2
YXRlIGVtYWlsIHNlbnQgdG8gb3RoZXJzIHByZXZpb3VzbHksIGRlc2NyaWJlcyB0aGUgaWRlYSBj
bGVhcmx5IGVub3VnaC4gTm90ZSB0aGF0IHNvbWUgdGhpbmdzIG5lZWQgdG8gYmUgcmVmaW5lZDsg
ZS5nLiB3aGF0IGhhcHBlbnMgd2hlbiB0aGUgY2xpZW50IGd1ZXNzZXMgdGhlIHNlcnZlcidzIEVD
REggcGFyYW1ldGVyIHJlcXVpcmVtZW50cyB3cm9uZ2x5Lg0KDQpGaXJzdCwgbGV0J3MgYXNzdW1l
IHRoYXQgd2UgY2FuIHJlc3RyaWN0IHRoaW5ncyB0byBlcGhlbWVyYWwga2V5IGV4Y2hhbmdlIG1l
Y2hhbmlzbXM6IFRMU19FQ0RIRV8qIGFuZCBUTFNfREhFXyouIEZvciBzaW1wbGljaXR5LCBsZXQn
cyByZXN0cmljdCB0aGluZ3MgZnVydGhlciBhbmQgdGFsayBhYm91dCBUTFNfRUNESEVfKi4gQWxz
bywgbGV0J3MgYXNzdW1lIGZvciBub3cgdGhhdCB3ZSBkb24ndCBjYXJlIGFib3V0IHRoZSBjYXNl
IHdoZXJlIHRoZXJlIGFyZSBjbGllbnQgY2VydGlmaWNhdGVzLg0KDQpMZXQncyBpbWFnaW5lIHRo
YXQgYSBjbGllbnQgY2FuIGd1ZXNzIHRoZSAxLTMgbW9zdCBsaWtlbHkgY3VydmVzIHRoYXQgdGhl
IHNlcnZlciBpcyBsaWtlbHkgdG8gY2hvb3NlIGZvciB0aGUgRUNESEUga2V5IGV4Y2hhbmdlLiBU
aGF0IGlzIGFjdHVhbGx5IHByZXR0eSBlYXN5IG5vdywgZXZlbiB3aXRob3V0IGFueSBwcmlvciBj
b250YWN0IHRvIHRoZSBzZXJ2ZXIsIGJlY2F1c2UgdGhlIHNlcnZlciBpcyBhbG1vc3QgYWx3YXlz
IGdvaW5nIHRvIGNob29zZSBQLTI1NiwgUC0zODQsIFAtNTIxLCBpbiB0aGF0IG9yZGVyLiBTbywg
dGhlIGNsaWVudCBjb3VsZCBwcmVzdW1wdHVvdXNseSBnZW5lcmF0ZSBpdHMgb3duIHByaXZhdGUv
cHVibGljIGtleXBhaXIgZm9yIHRob3NlIDEtMyBjdXJ2ZXMgYmVmb3JlIGl0IGV2ZW4gY29ubmVj
dHMgdG8gdGhlIHNlcnZlciwgcmlnaHQ/IFdlbGwsIHRoZW4gaXQgY291bGQganVzdCBpbmNsdWRl
IHRoZSBwdWJsaWMga2V5cyBpbiBhbiBleHRlbnNpb24gaW4gaXRzIGNsaWVudCBoZWxsbywgcmln
aHQ/IFRoZW4sIHdoZW4gdGhlIHNlcnZlciBoYXMgZmluaXNoZWQgaXRzIFNlcnZlckhlbGxvLi4u
U2VydmVySGVsbG9Eb25lLCBpdCBoYXMgZW5vdWdoIGluZm9ybWF0aW9uIHRvIHNlbmQgQ2hhbmdl
Q2lwaGVyU3VpdGUgYW5kIEZpbmlzaGVkIGp1c3QgbGlrZSBhIHJlc3VtcHRpb24gaGFuZHNoYWtl
LiBUaGF0IGlzLCB3ZSd2ZSB0cmFuc2Zvcm1lZCB0aGUgVExTIGZ1bGwgaGFuZHNoYWtlIGZyb20g
YSAyLVJUVCwgY2xpZW50LXNlbmRzLWFwcGxpY2F0aW9uLWRhdGEtZmlyc3QgaGFuZHNoYWtlIGlu
dG8gYSAxLVJUVCBzZXJ2ZXItc2VuZHMtYXBwbGljYXRpb24tZGF0YS1maXJzdCBoYW5kc2hha2Ug
dGhhdCBpcyBlcXVpdmFsZW50IHRvIHRoZSAyLVJUVCB2ZXJzaW9uLCBpbiB0ZXJtcyBvZiBzZWN1
cml0eSBwcm9wZXJ0aWVzLg0KKENvbXBhcmUgdGhpcyB0byBGYWxzZSBTdGFydCBvciBTbmFwIFN0
YXJ0LCB3aGljaCBib3RoIGhhdmUgd2Vha2VyIHNlY3VyaXR5IHByb3BlcnRpZXMuKSBJbiBvdGhl
ciB3b3JkcywgaXQgaXMgYmV0dGVyIHBlcmZvcm1hbmNlIGVmZmVjdGl2ZWx5IGZvciBmcmVlLg0K
DQpOb3csIEluIG9yZGVyIGZvciB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgdG8gYWdyZWUgdG8gZG8g
dGhpcywgdGhleSBoYXZlIHRvIGFncmVlIG9uIGl0IHZpYSBzb21lIFRMUyBleHRlbnNpb24tLW5h
bWVseSwgdGhlIFRMUyBleHRlbnNpb24gdGhhdCBjb250YWlucyB0aGUgY2xpZW50J3MgcHVibGlj
IGtleXMuIE5vdywgaW1hZ2luZSB0aGF0IHRoaXMgc2FtZSBleHRlbnNpb24gYWxzbyBjb250YWlu
ZWQgYSBudW1iZXIgTiB3aGljaCBtZWFucyAidGhlIGZpcnN0IGZvdXIgYnl0ZXMgb2YgYXBwbGlj
YXRpb24gZGF0YSBjb250YWluIGEgbnVtYmVyIE47IGZvbGxvd2luZyB0aGF0IGFyZSBOIGJ5dGVz
IG9mIGFwcGxpY2F0aW9uIGRhdGEgYXJlIGFjdHVhbGx5IGNvbm5lY3Rpb24tc3BlY2lmaWMgbWV0
YWRhdGEgdGhhdCBpcyBwcmVmaXhlZCB0byB0aGUgYWN0dWFsIGFwcGxpY2F0aW9uIGRhdGEuIg0K
DQpUaGUgcGVlciBUTFMgaW1wbGVtZW50YXRpb24gd291bGQgcHJvY2VzcyB0aGVzZSBOIGJ5dGVz
IG9mIG1ldGFkYXRhIGJ5IHJlYWRpbmcgdGhlbSBhbmQgZXhwb3NpbmcgdGhlbSB0byB0aGUgYXBw
bGljYXRpb24gdGhyb3VnaCBzb21lIEFQSSwgYW5kIHRoZW4gcGFzc2luZyB0aGUgYWN0dWFsIGFw
cGxpY2F0aW9uIGRhdGEgdG8gdGhlIGFwcGxpY2F0aW9uLg0KDQpXaGF0IGtpbmQgb2YgbWV0YWRh
dGEgd291bGQgYmUgaW4gdGhpcyBoZWFkZXI/IEF0IGEgbWluaW11bSwgSSB3b3VsZCBleHBlY3Qg
dGhhdCB0aGUgc2VydmVyIHdvdWxkIGluY2x1ZGUgaW5mb3JtYXRpb24gc3VjaCBhcyB3aGF0IHBy
b3RvY29scyBpdCBzdXBwb3J0cyAocmVwbGFjaW5nIE5QTiksIHdoZXRoZXIgdGhlIHNlcnZlciBp
cyBIU1RTIChpLmUuIGJyaW5naW5nIEhTVFMgdG8gSU1BUCwgU01UUCwgUE9QLCBJUkMsIGV0Yy4p
LCB0aGUgc2VydmVyJ3Mga2V5IHBpbm5pbmcgaW5mb3JtYXRpb24gKHJlcGxhY2luZyBIUEtQKSwg
YW5kIHdoZXRoZXIgdGhlIHNlcnZlciB3YW50cyB0byBmb3JjZSBPQ1NQIHN0YXBsaW5nIChyZXBs
YWNpbmcgdGhlIE11c3QtU3RhcGxlIGhlYWRlciB0aGF0IEkgd2lsbCBwcm9wb3NlIHNvb24pLiBG
b3IgdGhlIGNsaWVudCwgaXQgd291bGQgaW5jbHVkZSBpbmZvcm1hdGlvbiBzdWNoIGFzIHdoYXQg
cHJvdG9jb2wgaXQgaGFzIGNob3NlbiB0byBzcGVhayAocmVwbGFjaW5nIE5QTikgYW5kIGl0cyBj
aGFubmVsIElEIGtleS9wcm9vZiBvZiBwb3NzZXNzaW9uIChyZXBsYWNpbmcgY2hhbm5lbCBJRCku
DQoNCkFib3ZlLCBJIGp1c3QgZGVzY3JpYmVkIGEgVExTIGhhbmRzaGFrZSB0aGF0IGxvb2tzIGxp
a2UgdGhpczoNCg0KSCBDbGllbnRIZWxsbw0KICAoQ2xpZW50IEtleSkgIC0tLS0tLS0tLS0tLS0t
LS0+DQogICAgICAgICAgICAgICAgPC0tLS0tLS0tLS0tLS0tLS0gSCBTZXJ2ZXJIZWxsbw0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEggQ2VydGlmaWNhdGUNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBIIENlcnRpZmljYXRlU3RhdHVzDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgSCBTZXJ2ZXJLZXlFeGNoYW5nZQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIEggU2VydmVySGVsbG9Eb25lDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgSCBOZXdTZXNzaW9uVGlja2V0DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgQyBDaGFuZ2VDaXBoZXJTcGVjDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgSCBGaW5pc2hlZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEg
VHJ1c3QgTWV0YWRhdGEgQyBDaGFuZ2VDaXBoZXJTcGVjIC0tLS0tLS0tLS0tLS0+IEggRmluaXNo
ZWQgQSBUcnVzdCBNZXRhZGF0YSBBIEFwcGxpY2F0aW9uIGRhdGEgPC0tLS0tLS0tLS0tLT4gQSBB
cHBsaWNhdGlvbiBkYXRhDQoNCg0KTm93LCB3ZSBtaWdodCB3b3JyeSB0aGF0IHNvbWUgaW50ZXJt
ZWRpYXJpZXMgd2lsbCBjaG9rZSBvbiB0aGlzIHN0cmFuZ2UtbG9va2luZyBoYW5kc2hha2U/IENh
biB3ZSB0dXJuIGl0IGludG8gc29tZXRoaW5nIHRoYXQgdGhleSB3b24ndCBjaG9rZSBvbj8gWWVz
LCB3ZSBjYW46DQoNCkggQ2xpZW50SGVsbG8NCkggKENsaWVudCBLZXkpICAtLS0tLS0tLS0tLS0t
LS0tPg0KICAgICAgICAgICAgICAgIDwtLS0tLS0tLS0tLS0tLS0tIEggU2VydmVySGVsbG8NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChTZXJ2ZXIgS2V5KQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIEMgQ2hhbmdlQ2lwaGVyU3BlYw0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIEggRmluaXNoZWQNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBBIENlcnRpZmljYXRlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgQSBDZXJ0aWZpY2F0ZVN0YXR1cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IEEgU2VydmVyS2V5RXhjaGFuZ2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBB
IFNlcnZlckhlbGxvRG9uZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEgTmV3
U2Vzc2lvblRpY2tldA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEgVHJ1c3Qg
TWV0YWRhdGEgQyBDaGFuZ2VDaXBoZXJTcGVjIC0tLS0tLS0tLS0tLS0+IEggRmluaXNoZWQgQSBU
cnVzdCBNZXRhZGF0YSBBIEFwcGxpY2F0aW9uIGRhdGEgPC0tLS0tLS0tLS0tLT4gQSBBcHBsaWNh
dGlvbiBkYXRhDQoNCk5vdGUgdGhhdCBhbGwgdGhlIGFwcGxpY2F0aW9uIGRhdGEgcmVjb3JkcyBh
cmUgZW5jcnlwdGVkIHNvIHRoZSBpbnRlcm1lZGlhcnkgY2FuJ3QgcmVhZCB0aGVtLS10aGF0IGlz
LCBpdCBjYW4ndCB0ZWxsIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gbWV0YWRhdGEgYW5kIGFjdHVh
bCBhcHBsaWNhdGlvbiBkYXRhLCBzbyBpdCBsb29rcyBsaWtlIHRoaXMgdG8NCnRoZW06DQoNCkgg
Q2xpZW50SGVsbG8NCkggKENsaWVudCBLZXkpICAtLS0tLS0tLS0tLS0tLS0tPg0KICAgICAgICAg
ICAgICAgIDwtLS0tLS0tLS0tLS0tLS0tIEggU2VydmVySGVsbG8NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIChTZXJ2ZXIgS2V5KQ0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIEMgQ2hhbmdlQ2lwaGVyU3BlYw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIEggRmluaXNoZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBIEFw
cGxpY2F0aW9uIGRhdGEgQyBDaGFuZ2VDaXBoZXJTcGVjIC0tLS0tLS0tLS0tLS0+IEggRmluaXNo
ZWQgQSBBcHBsaWNhdGlvbiBkYXRhIDwtLS0tLS0tLS0tLS0+IEEgQXBwbGljYXRpb24gZGF0YQ0K
DQpJLmUuIGl0IGxvb2tzIGV4YWN0bHkgbGlrZSB0aGUgc2VydmVyIGZhbHNlIHN0YXJ0IGhhbmRz
aGFrZSB0byBhbiBvdXRzaWRlIG9ic2VydmVyLiBUaGlzIHNob3VsZCBtaW5pbWl6ZSB0aGUgY29t
cGF0aWJpbGl0eSBpbXBhY3Qgb2Ygc3VwcG9ydGluZyB0aGUgbWVjaGFuaXNtLg0KDQpCZXNpZGVz
IGNyZWF0aW5nIGEgZnJhbWV3b3JrIHNpbWlsYXIgdG8gImVuY3J5cHRlZCBleHRlbnNpb25zIiB0
aGF0IHlvdSBjb3VsZCB1c2UgZm9yIGNoYW5uZWwgSUQsIHRoaXMgYWxzbyBnaXZlcyB1cyBlbmNy
eXB0ZWQgc2Vzc2lvbiB0aWNrZXRzLCB3aGljaCBtZWFucyB0aGF0IHRoZXJlIGlzIGEgY2VydGFp
biBhbW91bnQgb2YgdW5saW5rYWJpbGl0eSBiZXR3ZWVuIGNvbm5lY3Rpb25zIHRoYXQgd2Fzbid0
IHRoZXJlIG9yaWdpbmFsbHkuIEZ1cnRoZXIsIG1ha2luZyB0aGUgQ2VydGlmaWNhdGUgYW5kIENl
cnRpZmljYXRlU3RhdHVzIG1lc3NhZ2VzIG9wYXF1ZSB0byBvdXRzaWRlcnMgYWxsb3dzIHVzIHRv
IGFwcGx5IGNvbXByZXNzaW9uIHRvIHRob3NlIHBhcnRzIG9mIHRoZSBoYW5kc2hha2Ugd2l0aG91
dCB3b3JyeWluZyBhYm91dCBpbnRlcm1lZGlhdGVzIGNob2tpbmcgb24gdGhlIGNvbXByZXNzZWQg
ZGF0YS4gQW5kL29yIHdlIGNhbiBkZWZpbmUgbmV3LCBub24tWC41MDkgY2VydGlmaWNhdGUgZm9y
bWF0cyB3aXRob3V0IGZlYXIgb2YgYnJlYWthZ2UgYnkgaW50ZXJtZWRpYXJpZXMuIFdlIGNvdWxk
IGFsc28gYWRkIGJhY2sgY2xpZW50IGNlcnRpZmljYXRlcyBieSBhZGRpbmcgQ2VydGlmaWNhdGUg
YW5kIENlcnRpZmljYXRlVmVyaWZ5IG1lc3NhZ2VzIGJlZm9yZSB0aGUgY2xpZW50J3MgTWV0YWRh
dGEuIFRoaXMgd291bGQgZ2l2ZSB1cyBlbmNyeXB0ZWQgY2xpZW50IGNlcnRpZmljYXRlcy4gQWxz
bywgYnkgbWFuZGF0aW5nIFRMUyAxLjIgZm9yIHRoaXMgbWVjaGFuaXNtLCB3ZSBjYW4gb3Zlcmxv
YWQgaXQgYXMgYSBUTFMgZG93bmdyYWRlIHByZXZlbnRpb24gbWVjaGFuaXNtIChpZiB3ZSBjYW4g
c29sdmUgdGhlIGRvd25ncmFkZS10by1TU0wzLjAtd2l0aG91dC1leHRlbnNpb25zIGlzc3VlKS4g
SWYgd2Ugd2VyZSB0byBlc3RhYmxpc2ggc29tZSBzdGFuZGFyZHMgZm9yIHBhZGRpbmcgc2Vzc2lv
biB0aWNrZXRzIHRvIGEgY2VydGFpbiBzaXplLCB0aGVuIHRoZSBjbGllbnQgY291bGQgYWx3YXlz
IHNlbmQgYSBzZXNzaW9uIHRpY2tldCBpbiBldmVyeSBjbGllbnQgaGVsbG8gKGVpdGhlciBhIHJl
YWwgb25lLCBvciBhIHJhbmRvbWx5LWdlbmVyYXRlZCBvbmUgb2YgdGhlIHJpZ2h0IHNpemUpLg0K
VGhpcyB3b3VsZCwgSSBob3BlLCBlbGltaW5hdGUgdGhlIHBvc3NpYmlsaXR5IHRvIGRldGVybWlu
ZSB3aGV0aGVyIG9yIGEgaGFuZHNoYWtlIGlzIGEgcmVzdW1wdGlvbiBoYW5kc2hha2Ugb3IgYSBm
dWxsIGhhbmRzaGFrZS0taS5lLiBtYXNrIHdoZXRoZXIgb3Igbm90IHRoZSB1c2VyIGhhcyB2aXNp
dGVkIHRoZSBzaXRlIGJlZm9yZS9yZWNlbnRseS4NCihNZWFzdXJpbmcgdGhlIHRpbWluZyBvZiB0
aGUgc2VydmVyJ3Mgc2lkZSBvZiB0aGUgaGFuZHNoYWtlIHdvdWxkIGdpdmUgdGhpbmdzIGF3YXks
IGJ1dCB0aGF0IGlzIGEgaGFyZGVyIGF0dGFjayB0byBwdWxsIG9mZi4pDQoNCkF0IGEgaGlnaGVy
IGxldmVsLCB0aGlzIGJyZWFrcyBUTFMgaW50byB0aHJlZSBkaXN0aW5jdCBwaGFzZXM6ICgxKSBU
TFMgaXMgdGhlIGxheWVyIHRoYXQgZXN0YWJsaXNoZXMgdGhlIGtleXMgYW5kIGF1dGhlbnRpY2F0
ZXMgdGhlIGNvbm5lY3Rpb24gd2l0aCB0aG9zZSBrZXlzLCBtdXR1YWxseSBhbm9ueW1vdXNseSwg
KDIpIHRoZSBUcnVzdCBNZXRhZGF0YSBwaGFzZSBpcyB3aGVyZSB0aGUgVExTIHN0YWNrIGFuZCB0
aGUgYXBwbGljYXRpb24gd29yayB0b2dldGhlciB0byBlc3RhYmxpc2ggdHJ1c3Qgb2YgdGhlIHBl
ZXIgYW5kIG9mIHRoZSBwZWVyJ3MgZGF0YSwgYW5kDQooMykgdGhlIGFwcGxpY2F0aW9uIGRhdGEg
cGhhc2UgaXMgd2VsbCwgdGhlIGFwcGxpY2F0aW9uIGRhdGEuIEdpdmVuIHRoaXMsIHdlIGNvdWxk
IHNheSB0aGF0IHRoZSBUTFMgd29ya2luZyBncm91cCBpcyByZXNwb25zaWJsZSBmb3IgZGVmaW5p
bmcgdGhlIGZpcnN0IHBoYXNlIChUTFMpIHdoaWxlIHBlcmhhcHMgc29tZSBvdGhlciBncm91cHMg
Y291bGQgZGVmaW5lIHRoZSBzZWNvbmQgcGhhc2UgKFRydXN0IE1ldGFkYXRhKS4gTXkgaG9wZSBp
cyB0aGF0IHRoZSB0cnVzdCBtZXRhZGF0YSBsYXllciBtaWdodCBiZSB1c2VmdWwgZXZlbiBpbiBu
b24tVExTIHByb3RvY29scy4NCg0KQ2hlZXJzLA0KQnJpYW4NCg==

From pascal.urien@gmail.com  Mon Dec  9 12:39:13 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09021AE0A7 for ; Mon,  9 Dec 2013 12:39:13 -0800 (PST)
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 Wyc-_fjNMQmt for ; Mon,  9 Dec 2013 12:39:11 -0800 (PST)
Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 872D31AE07F for ; Mon,  9 Dec 2013 12:39:11 -0800 (PST)
Received: by mail-bk0-f54.google.com with SMTP id v16so1592707bkz.27 for ; Mon, 09 Dec 2013 12:39:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tSxHcOkCPx70KdRnjwhcdTYNXBrNI8Pp6ZQ4Go96X1o=; b=j88u8CEbdwsfj+HEXg1JDIJjWNLKpJy9OlMgDGpVnWGvgbBcMCvmhnmL7WEq4VipF1 h4BthrOiBKM9f8YS6Hm00CB8ISaN+vTV3sqcaK4Z/2mhhcZt8YrTBke61EpJpHvlbsSW RENQCxAfeTvQDqYmuSgo4ubDJZAzGD2b84ulHwE2R7ZeLzGHKcJw40jkIPQqaXz3pPgq 4JO6kvo3zqyrPdAmPlzjxaWSrkv4fjHrVB21RaOPDhJUq16FzcqnhUxaD/H9MBvbJDpX Dx7fh3PjQaIGxmB6SeAoLjyDeAjYysaSEr08FrVof07paeJDujTNU3hFjDp8SRjbCtCG mA0A==
MIME-Version: 1.0
X-Received: by 10.205.68.69 with SMTP id xx5mr1262926bkb.143.1386621545793; Mon, 09 Dec 2013 12:39:05 -0800 (PST)
Received: by 10.204.51.141 with HTTP; Mon, 9 Dec 2013 12:39:05 -0800 (PST)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>   
Date: Mon, 9 Dec 2013 21:39:05 +0100
Message-ID: 
From: Pascal Urien 
To: Andrei Popov 
Content-Type: multipart/alternative; boundary=f46d041039d3acfa2c04ed1ffcd4
Cc: Peter Gutmann , "" 
Subject: Re: [TLS] ALPN concerns
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 20:39:13 -0000

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

Hi all


2013/11/19 Andrei Popov 

> Hi Brian,
>
> I totally agree that we need to encrypt more information in the TLS
> handshake, including the client cert and the contents of various
> extensions, such as SNI and ALPN. Unfortunately, the only way to make this
> information confidential in the existing versions of TLS is to incur
> additional round-trips (by using renegotiation, or otherwise exchanging
> messages after the TLS handshake is complete). This is one of the reasons
> why the TLS WG is pushing hard to make progress on TLS1.3.
>

Encryption of the client's certificate is possible without renegociation

See
http://tools.ietf.org/id/draft-urien-badra-eap-tls-identity-protection-01.txt

The idea is very simple, just add a key for the client's certificate
encryption such as

  enc-key = PRF(SecurityParameters.master_secret,
                 "client_certificate",
                  SecurityParameters.client-random +
                  SecurityParameters.server-random);

Some slides from the IETF 66th

http://www.ietf.org/proceedings/66/slides/emu-2/sld1.htm

This feature has been implemented and tested with TLS1.0


Regards

Pascal Urien

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


Hi all


2013/11/19 Andrei Popov <Andrei.Popov@microsoft.com=
>


Hi Brian,



I totally agree that we need to encrypt more information in the TLS handsha=
ke, including the client cert and the contents of various extensions, such =
as SNI and ALPN. Unfortunately, the only way to make this information confi=
dential in the existing versions of TLS is to incur additional round-trips =
(by using renegotiation, or otherwise exchanging messages after the TLS han=
dshake is complete). This is one of the reasons why the TLS WG is pushing h=
ard to make progress on TLS1.3.



Encryption of the client's certificate=
 is possible without renegociation

See
<=
a href=3D"http://tools.ietf.org/id/draft-urien-badra-eap-tls-identity-prote=
ction-01.txt">http://tools.ietf.org/id/draft-urien-badra-eap-tls-identity-p=
rotection-01.txt



The idea is very simple, just add a key for the client&=
#39;s certificate encryption such as

=A0 enc-key =
=3D PRF(SecurityParameters.master_secret, 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 "client_certificate", 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SecurityParameters.clie=
nt-random + 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Securit=
yParameters.server-random); 

Some slides from the =
IETF 66th




This feature has been implemented and tested with TLS1.=
0


Regards

=
Pascal Urien



--f46d041039d3acfa2c04ed1ffcd4--

From Andrei.Popov@microsoft.com  Mon Dec  9 13:00:03 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1465B1AE565 for ; Mon,  9 Dec 2013 13:00:03 -0800 (PST)
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 5RGNnh00aIqK for ; Mon,  9 Dec 2013 13:00:01 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 38BF51AE521 for ; Mon,  9 Dec 2013 13:00:01 -0800 (PST)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB417.namprd03.prod.outlook.com (10.141.92.12) with Microsoft SMTP Server (TLS) id 15.0.837.10; Mon, 9 Dec 2013 20:59:55 +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.0837.004; Mon, 9 Dec 2013 20:59:55 +0000
From: Andrei Popov 
To: Alfredo Pironti , Brian Smith 
Thread-Topic: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
Thread-Index: AQHO9PKZagDAr9CG9EmXG7XxRFhC8ZpMCHOAgAAIboCAAEBTQA==
Date: Mon, 9 Dec 2013 20:59:54 +0000
Message-ID: 
References:    
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::3]
x-forefront-prvs: 00550ABE1F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(13464003)(377454003)(51704005)(52604005)(199002)(189002)(24454002)(87266001)(53806001)(63696002)(74316001)(74366001)(49866001)(76576001)(47736001)(47976001)(81342001)(80976001)(51856001)(46102001)(19580395003)(15202345003)(2656002)(4396001)(74876001)(15975445006)(54356001)(81686001)(19580405001)(83322001)(74706001)(81816001)(47446002)(90146001)(54316002)(56776001)(74502001)(56816005)(77982001)(33646001)(59766001)(76786001)(31966008)(87936001)(74662001)(79102001)(81542001)(50986001)(85306002)(76482001)(76796001)(69226001)(80022001)(65816001)(83072002)(85852003)(3826001)(24736002)(376185003); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB417; H:BL2PR03MB419.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::3; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "" , Peter Gutmann 
Subject: Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 21:00:03 -0000

To add to Alfredo's points, the problem is that http2-tls-relaxed is explic=
itly MITM-able by design, and is intended only to prevent passive attacks.

If I understand correctly, an active attacker can prevent http2-tls-relaxed=
 from happening by manipulating Alt-Svc headers, regardless of whether ALPN=
 or NPN is used.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Alfredo Pironti
Sent: Monday, December 9, 2013 8:41 AM
To: Brian Smith
Cc: Peter Gutmann; 
Subject: Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure,=
 compared to NPN (was Re: ALPN concerns)

Hi Brian,

Thanks for clarifying, I now understand the use case you were referring to.=
 I especially missed case 1. I have further comments, that I put inline.

On Mon, Dec 9, 2013 at 5:10 PM, Brian Smith  wrote:
> On Mon, Dec 9, 2013 at 7:23 AM, Alfredo Pironti  wrot=
e:
>>> The case where the server does not use a certificate that the client=20
>>> would verify correctly as it would in the "normal" HTTPS case is not=20
>>> interesting. However, the case where opportunistic encryption is=20
>>> being used with a certificate that *is* valid (as defined by=20
>>> RFC5280, et
>>> al.) is interesting.
>>
>> I think this pre-condition makes your counter-example invalid.
>> A client that only accepts valid certificates is in practice only=20
>> implementing http2, not http2-tls-relaxed, in that client's behavior=20
>> doesn't change.
>
> Let's say the client is connecting to example.org:443 using TLS. There=20
> are two interesting possibilities:
>
> 1. The client could be resolving an http:// link that uses=20
> opportunistic encryption. In this case, if the client supports=20
> opportunistic encryption, the client would support "http2-tls-relaxed"
> and "http2-tls" (and "http1-tls") and a MitM attack, if attempted,=20
> would succeed.
>
> 2. The client could be resolving an https:// link. In this case, the=20
> client would only support "http2-tls" (and "http1-tls") and a MitM=20
> attack, if attempted, would fail in a end-user-notable way.
>
> With ALPN, it is trivial for the MitM to determine which case it is=20
> and act accordingly. With NPN, it is not trivial (it requires=20
> correlating data from multiple connections) and in many cases it may=20
> be impossible (e.g. when an HTTP cache has stored the response with=20
> the alternate-service upgrade header).

With ALPN, the client could always send both "http2-tls-relaxed" and "http2=
", making its behavior indistinguishable in cases 1 and 2. Isn't this enoug=
h to make your attacker desist?

For functionality, you may say that allowing "http2-tls-relaxed" in case 2 =
may lead the server to send an invalid certificate when it could have sent =
a valid one (and so one needs to distinguish the two cases). Do we have a r=
ealistic scenario of this? I mean: a server that prefers a "mitm-able" conn=
ection over a more secure one. A case where the server would send a invalid=
 certificate to disguise its identity doesn't seem to work, because any fur=
ther "http2"-only connection (from any unauthenticated client) may reveal i=
ts identity anyway.

(I don't want to defend ALPN at all costs, but maybe what I propose is enou=
gh to satisfy your use case? I'd prefer to conceal the upper protocol from =
the attacker, but this has to be done at the same security that other TLS-p=
rotected data get, and I find NPN does not quite achieve this.)

Cheers,
Alfredo

>
>> Indeed, but under the assumption that only valid certificates are=20
>> accepted, the behaviors coincide to "http2".
>
> In the case of opportunistic encryption, we would support both valid=20
> and invalid certificates. In the case of normal "http2-tls" and=20
> "http1-tls", we would support only valid certificates.
>
> Cheers,
> Brian
>
>
> --
> Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

From martin.thomson@gmail.com  Mon Dec  9 13:32:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340041AE08B for ; Mon,  9 Dec 2013 13:32:41 -0800 (PST)
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 LkBgG7woXko3 for ; Mon,  9 Dec 2013 13:32:40 -0800 (PST)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D91D91AE5B4 for ; Mon,  9 Dec 2013 13:32:39 -0800 (PST)
Received: by mail-we0-f170.google.com with SMTP id w61so4145527wes.29 for ; Mon, 09 Dec 2013 13:32:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=axVeRH+c7o5ML+vGvofxUbDCBFEjaUcWY2lwCYQa+G4=; b=QEt25C80XeO02Dnd9gk7CQbOq178LyppwzTN90ZCEJ3QJNRRZdBhACLjaApGC5/zNQ N4RRAR9FIBIMoy2qGzubuyQb5T8nGuLQ+VaBbPMCJNQgTrKF3R9RwkHPgJ0BQdCisMxE Q2K5Tlpl3QAK+CMSfq4LBbZDNzuYaBs3fv4Jp5MvhcSHme5T39ccFHuMV0pisH6qq2OS 9Ya/OTiLPOsSdbC+qOGBXWw9DbhAQnI7Erfcz74zQRKEUF7uR96F/JHu2pHwmWzqxCDW bqlrTEn175t8Fu0wdwdKYqyiJzhleXXzNYVgN1Iufao6k22sIX6AThzbW1Wck4wX7qPh clMA==
MIME-Version: 1.0
X-Received: by 10.180.108.162 with SMTP id hl2mr16138372wib.56.1386624754444;  Mon, 09 Dec 2013 13:32:34 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Mon, 9 Dec 2013 13:32:34 -0800 (PST)
In-Reply-To: 
References:     
Date: Mon, 9 Dec 2013 13:32:34 -0800
Message-ID: 
From: Martin Thomson 
To: Andrei Popov 
Content-Type: text/plain; charset=UTF-8
Cc: Peter Gutmann , Alfredo Pironti , "" 
Subject: Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 09 Dec 2013 21:32:41 -0000

On 9 December 2013 12:59, Andrei Popov  wrote:
> If I understand correctly, an active attacker can prevent http2-tls-relaxed from happening by manipulating Alt-Svc headers, regardless of whether ALPN or NPN is used.

An active attacker can always exploit a willingness on the part of a
client to settle for something less than their best effort at
authenticating the server, yes.  This goes for Alt-Svc, Upgrade, or
any other scheme where the default behaviour is HTTP/1.1 in the clear.
 As long as the client is willing to do anything without
authentication, they are vulnerable to an active attack of this
nature.

From ekr@rtfm.com  Mon Dec  9 17:21:43 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE3B1ADF48 for ; Mon,  9 Dec 2013 17:21:43 -0800 (PST)
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 wisXnZ--tU8U for ; Mon,  9 Dec 2013 17:21:42 -0800 (PST)
Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id A300B1ADED8 for ; Mon,  9 Dec 2013 17:21:41 -0800 (PST)
Received: by mail-we0-f178.google.com with SMTP id u57so4218849wes.23 for ; Mon, 09 Dec 2013 17:21:36 -0800 (PST)
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=mM8YhIrl1zrMGPLo+FasbT4RvZxltuuAFgjt6xkKQ0Y=; b=HpWIj/SnttPpBlD8MiOARSlYC8EBfNg3jFy/MQl3jCO/2s675I1oSNSmYeTMKUNCUL /XwcFy1Q3ngQoxj2B7qGkiKZkoN/A9ZyFDtJ3aPa0gl4EFpufszuRPRyEiaDQRh2QqxE gTd8+HY1IGK95oHP4VsBEYnxIFwlU2WIyQLirTmGCNgClwWvBE/yRs57s+Xd1zP+60HX l7YBBrytENmB9VhmzRgkm7jhGhCu/9o2XICqPOoYCSkoS6Lpta+mAXV8jrWzq0wkcvtX JZersCQWWZi5/09f0p1rPk5MBwv7LWOHef201+zjSDIzaz8WwXk/SpIzTOOmjddJUdbS nOzQ==
X-Gm-Message-State: ALoCoQlqDHF02wdZdaq4r7q9ffYouR5zscmWWO8CjGRtIXaqk978wy2epLKgXGdqQuIM/BMXqkbl
X-Received: by 10.194.90.144 with SMTP id bw16mr18299529wjb.1.1386638496226; Mon, 09 Dec 2013 17:21:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Mon, 9 Dec 2013 17:20:56 -0800 (PST)
X-Originating-IP: [59.115.40.240]
In-Reply-To: 
References:  
From: Eric Rescorla 
Date: Tue, 10 Dec 2013 09:20:56 +0800
Message-ID: 
To: Martin Thomson 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" , Peter Gutmann 
Subject: Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 01:21:43 -0000

On Tue, Dec 10, 2013 at 1:16 AM, Martin Thomson
 wrote:
> On 9 December 2013 05:56, Brian Smith  wrote:
>> Please see http://tools.ietf.org/html/draft-nottingham-http2-encryption-01#section-2.1
>> (read the whole document, but section 2.1 is especially interesting).
>> That document defines a mechanism wherein, through protocol
>> negotiation, a web browser and server can agree on a "relaxed" form of
>> TLS for HTTP where the client does not authenticate the server's
>> certificate. The goal is to enable a form of opportunistic encryption
>> to HTTP.
>
> My feedback to Mark on this point was that this negotiation was
> completely unnecessary.
>
> A server already has a way to signal that it doesn't care about
> certain security properties of a resource.  It does that by omitting
> the 's' in the resource URL.
>
> A client is then left to decide whether it cares about those
> properties.  What requirements are then placed on the subsequent
> interactions are up to the client.

Exactly so. I don't see an reason why one would wish to advertise this.

-Ekr

From brian@briansmith.org  Mon Dec  9 18:15:48 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78C31AE0D8 for ; Mon,  9 Dec 2013 18:15:48 -0800 (PST)
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 wue34DI5vWF1 for ; Mon,  9 Dec 2013 18:15:47 -0800 (PST)
Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id DB3CF1AE0F8 for ; Mon,  9 Dec 2013 18:15:46 -0800 (PST)
Received: by mail-qe0-f48.google.com with SMTP id gc15so3583860qeb.7 for ; Mon, 09 Dec 2013 18:15:41 -0800 (PST)
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=X2HLXeF8/Tl1APr4PUSHgz8S4YeyXzcxhRzw075QA2E=; b=O4LZt+vrrc6zVyhSaQqCIzKAFLG38chbPfvIk8XygnDbLtAUIYGlMCiR6lPrFpv/rn Zl8xTCFTVz5yfgyb4dUbGOIJYvgnh3DKgtpmBybPBn2yHWulvSMOXk+NvKdMplmUJCpw rBDujmLbpGUOjYv1OGcqUbrgpN6jDoKrWqbTktTDFxFtps0p21x4uq3RCZNiCS9nUCeL NlAnOA0gJlonN1b0279RieOpfC1J3XjYDPOCpFuVF8ARBLR4/XEU+EkeOiRq7eqsAKOy qs/j5xBPmrGSmZGDjVmr6E9mQgMF2BpTfbFg/40jVXqYBJ5zgvep8TU0RgZcRK+VpJ66 oXow==
X-Gm-Message-State: ALoCoQk/YAQ7AQBd4Q0zwoyCoh+2ZUHcXlLlIJBxk5hSRxKjCX1Xd4SaoQDXE/3CmEuEGDIEsrVm
MIME-Version: 1.0
X-Received: by 10.49.51.66 with SMTP id i2mr39251056qeo.26.1386641741733; Mon, 09 Dec 2013 18:15:41 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Mon, 9 Dec 2013 18:15:41 -0800 (PST)
X-Originating-IP: [63.245.219.54]
In-Reply-To: 
References:  
Date: Mon, 9 Dec 2013 18:15:41 -0800
Message-ID: 
From: Brian Smith 
To: Martin Thomson 
Content-Type: text/plain; charset=UTF-8
Cc: Peter Gutmann , "" 
Subject: Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 02:15:49 -0000

On Mon, Dec 9, 2013 at 9:16 AM, Martin Thomson  wrote:
> On 9 December 2013 05:56, Brian Smith  wrote:
>> Please see http://tools.ietf.org/html/draft-nottingham-http2-encryption-01#section-2.1
>> (read the whole document, but section 2.1 is especially interesting).
>> That document defines a mechanism wherein, through protocol
>> negotiation, a web browser and server can agree on a "relaxed" form of
>> TLS for HTTP where the client does not authenticate the server's
>> certificate. The goal is to enable a form of opportunistic encryption
>> to HTTP.
>
> My feedback to Mark on this point was that this negotiation was
> completely unnecessary.
>
> A server already has a way to signal that it doesn't care about
> certain security properties of a resource.  It does that by omitting
> the 's' in the resource URL.
>
> A client is then left to decide whether it cares about those
> properties.  What requirements are then placed on the subsequent
> interactions are up to the client.

Hi Martin,

If the server really doesn't care about the security or privacy
properties of a resource, then it wouldn't implement opportunistic
encryption in the first place, unless it was doing so purely as a
compatibility hack.

I think the point that you are making is that adding the
http2-tls-relaxed negotiation to the TLS handshake is pointless,
because you cannot securely negotiate anything on an insecure
connection. If so, then we'd say that the client MUST NOT advertise
the http2-tls-relaxed ALPN token, in order to avoid tipping off any
MitM that the connection will be unauthenticated. Is that right?

I think this means that, if the client supports opportunistic
encryption, then there would never be any way for the server to
securely know whether the client authenticated the connection or not,
so there's no secure way for a single server on a single port to
support both unauthenticated and authenticated TLS. Is this your
conclusion too?

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

From mrex@sap.com  Mon Dec  9 19:57:26 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171051AE168 for ; Mon,  9 Dec 2013 19:57:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.552
X-Spam-Level: 
X-Spam-Status: No, score=-8.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 EFJehvTNLURk for ; Mon,  9 Dec 2013 19:57:24 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id DC6BB1AC82B for ; Mon,  9 Dec 2013 19:57:23 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rBA3vGho023068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Dec 2013 04:57:17 +0100 (MET)
In-Reply-To: 
To: Nick Mathewson 
Date: Tue, 10 Dec 2013 04:57:16 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20131210035716.D7C3E1AB42@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
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, 10 Dec 2013 03:57:26 -0000

Nick Mathewson wrote:
> 
> One caveat here is that a server could tell different clients that it
> had different skew values, thereby creating yet another way to set
> stealth cookies.  You'd need to be sure not to share your view of
> server-local time across anonymous sessions, while roaming in a
> privacy-conscious way, and so on.

The server could also return client-specific session IDs in ServerHello,
or it could generate client-specific (EC)DHE public keys.

They is probably little you could do against a server that is
either subverted by some three-letter-agency or malicious all by itself.

-Martin

From jsalowey@cisco.com  Mon Dec  9 22:39:05 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A551AE1E9 for ; Mon,  9 Dec 2013 22:39:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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.001, 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 pIg8YUFKUhcZ for ; Mon,  9 Dec 2013 22:39:04 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EDB611AE2D1 for ; Mon,  9 Dec 2013 22:39:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2319; q=dns/txt; s=iport; t=1386657539; x=1387867139; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=lOpDRoV+vt5/dik9AgaMxaxUVgQDrNTzN8ieH6J71eo=; b=If2gsBEWKs9EgvAcuFT9iHF+q9xcjhtYbAxa5xFsYlFshIZVmTsTjvT4 GCOHpS4crS26979tMO9T1893JRTfQ9md1FUlJhRlC7zcqRKwfP19UrDE8 p1fYyNzvJ7vEWh2WENlNrlWQ2vQ8J/K6gMrd1+nSTGgTb4NS5+okurNIM Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAIa2plKtJV2d/2dsb2JhbABZgwc4U6cakXuBHBZ0giYBAQQ6TwIBCDAGEDIlAgSIFcBnF48MGIMIgRMDlDGDY5ITgymBaiQc
X-IronPort-AV: E=Sophos;i="4.93,864,1378857600"; d="scan'208";a="290458283"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 10 Dec 2013 06:38:58 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBA6cwEW019443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Dec 2013 06:38:58 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 00:38:58 -0600
From: "Joseph Salowey (jsalowey)" 
To: "" 
Thread-Topic: [TLS] TLS Charter Revision
Thread-Index: AQHO75QH12xj16hlv0SmAgrMfgWOIZpNamwA
Date: Tue, 10 Dec 2013 06:38:57 +0000
Message-ID: 
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>
In-Reply-To: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.33.249.48]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 06:39:05 -0000

Updated Charter text based on the discussion so far is below.  Changes:=20

1. Fixed typos=20
2. Third bullet to "Update record payload protection cryptographic
mechanisms and algorithms to address known weaknesses
in the CBC block cipher modes and to replace RC4."

Thanks,

Joe

The TLS (Transport Layer Security) working group was
established in 1996 to standardize a 'transport layer'
security protocol.  The basis for the work was SSL
(Secure Socket Layer) v3.0.  The TLS working group has
completed a series of specifications that describe the
TLS protocol v1.0, v1.1, and v1.2 and DTLS
(Datagram TLS) v1.2 as well as extensions to the
protocols and ciphersuites.

The primary purpose of the working group is to develop
(D)TLS v1.3.  Some of the main design goals are as follows,
in no particular order:

o Develop a mode that encrypts as much of the handshake as
is possible to reduce the amount of observable data to
both passive and active attackers.

o Develop modes to reduce handshake latency, which primarily
support HTTP-based applications, aiming for one roundtrip
for a full handshake and one or zero roundtrip for repeated
handshakes.

o Update record payload protection cryptographic
mechanisms and algorithms to address known weaknesses
in the CBC block cipher modes and to replace RC4.

o Reevaluate handshake contents, e.g.,: Is time needed in
client hello?  Should signature in server key exchange
cover entire handshake?  Are bigger randoms required?
Should there be distinct cipher list for each version?

A secondary purpose is to maintain previous version of
the (D)TLS protocols as well as to specify the use of
(D)TLS, recommendations for use of (D)TLS, extensions to
(D)TLS, and cipher suites.  However, changes or additions
to older versions of (D)TLS whether via extensions or
ciphersuites are discouraged and require significant
justification to be taken on as work items.

With these objectives in mind, the TLS WG will also place a priority
in minimizing gratuitous changes to TLS.

Milestone/Dates:

201311 - Out-of-Band Public Key Validation for TLS to IESG
201401 - Secure Password Ciphersuites for TLS to IESG
201404 - TLS ALPN (Application Layer Protocol Negotiation)
      Extension to IESG
201411 - (D)TLS 1.3 to IESG

From yaronf.ietf@gmail.com  Tue Dec 10 00:26:25 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B2A1AE123 for ; Tue, 10 Dec 2013 00:26:25 -0800 (PST)
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 tYZ5HusRPtwo for ; Tue, 10 Dec 2013 00:26:23 -0800 (PST)
Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9361AE0C4 for ; Tue, 10 Dec 2013 00:26:23 -0800 (PST)
Received: by mail-ea0-f182.google.com with SMTP id a15so2066502eae.13 for ; Tue, 10 Dec 2013 00:26:17 -0800 (PST)
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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=5lRvr+dcUaLzYbGqALMlJCKh0QlqhOHM3DVE/duUn5w=; b=TjcWvynn0B5cdiUDwFRMmm478RmKMSvSCUlMDJ3NYy4EDy6oCEUYQt9n5NqUB3PY04 zsBny3b19388iv2fJnw+tO2x/rjGKoVVjftUEhbUZPudSybOoD+L0VltxZ+USVFvmEc4 zxU+FzAKGI2W11k8MORCOmm1dj8Xtd7Akvp42/+rW1/OB00raF3wR+0smmdscjzV+R7L sFqurh+ewFyiaJqHaw9a9AYRRZjgVcT80EW435GnSrszXZCnbWcpyWrf0UHjfzDg4Mhy lGc/PV5TmGFbAbCXmWYLp3W0fz3Js9rnf+xAKh+dYxXldd5CpOlXrxB4Srz0d7Vusrm1 RyKQ==
X-Received: by 10.15.49.193 with SMTP id j41mr16433525eew.10.1386663977644; Tue, 10 Dec 2013 00:26:17 -0800 (PST)
Received: from [10.0.0.7] (93-173-133-53.bb.netvision.net.il. [93.173.133.53]) by mx.google.com with ESMTPSA id h48sm38281754eev.3.2013.12.10.00.26.14 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 00:26:14 -0800 (PST)
Message-ID: <52A6D025.3030902@gmail.com>
Date: Tue, 10 Dec 2013 10:26:13 +0200
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" ,  "" 
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 08:26:25 -0000

Hi Joe,

There is never-ending discussion on this list about servers that do not 
implement version negotiation correctly, and various solutions to 
prevent, secure, or provide policy for client-side version fallback. 
Shouldn't this be part of the group's charter?

Thanks,
	Yaron

On 12/10/2013 08:38 AM, Joseph Salowey (jsalowey) wrote:
> Updated Charter text based on the discussion so far is below.  Changes:
>
> 1. Fixed typos
> 2. Third bullet to "Update record payload protection cryptographic
> mechanisms and algorithms to address known weaknesses
> in the CBC block cipher modes and to replace RC4."
>
> Thanks,
>
> Joe
>
> The TLS (Transport Layer Security) working group was
> established in 1996 to standardize a 'transport layer'
> security protocol.  The basis for the work was SSL
> (Secure Socket Layer) v3.0.  The TLS working group has
> completed a series of specifications that describe the
> TLS protocol v1.0, v1.1, and v1.2 and DTLS
> (Datagram TLS) v1.2 as well as extensions to the
> protocols and ciphersuites.
>
> The primary purpose of the working group is to develop
> (D)TLS v1.3.  Some of the main design goals are as follows,
> in no particular order:
>
> o Develop a mode that encrypts as much of the handshake as
> is possible to reduce the amount of observable data to
> both passive and active attackers.
>
> o Develop modes to reduce handshake latency, which primarily
> support HTTP-based applications, aiming for one roundtrip
> for a full handshake and one or zero roundtrip for repeated
> handshakes.
>
> o Update record payload protection cryptographic
> mechanisms and algorithms to address known weaknesses
> in the CBC block cipher modes and to replace RC4.
>
> o Reevaluate handshake contents, e.g.,: Is time needed in
> client hello?  Should signature in server key exchange
> cover entire handshake?  Are bigger randoms required?
> Should there be distinct cipher list for each version?
>
> A secondary purpose is to maintain previous version of
> the (D)TLS protocols as well as to specify the use of
> (D)TLS, recommendations for use of (D)TLS, extensions to
> (D)TLS, and cipher suites.  However, changes or additions
> to older versions of (D)TLS whether via extensions or
> ciphersuites are discouraged and require significant
> justification to be taken on as work items.
>
> With these objectives in mind, the TLS WG will also place a priority
> in minimizing gratuitous changes to TLS.
>
> Milestone/Dates:
>
> 201311 - Out-of-Band Public Key Validation for TLS to IESG
> 201401 - Secure Password Ciphersuites for TLS to IESG
> 201404 - TLS ALPN (Application Layer Protocol Negotiation)
>        Extension to IESG
> 201411 - (D)TLS 1.3 to IESG
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

From stephen.farrell@cs.tcd.ie  Tue Dec 10 00:59:39 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9801AE0C4 for ; Tue, 10 Dec 2013 00:59:39 -0800 (PST)
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, RP_MATCHES_RCVD=-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 M9Xy8WNL6jWF for ; Tue, 10 Dec 2013 00:59:35 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B2D5F1ADF33 for ; Tue, 10 Dec 2013 00:59:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A79F0BE4D; Tue, 10 Dec 2013 08:59:29 +0000 (GMT)
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 hLBK7UpYrK03; Tue, 10 Dec 2013 08:59:27 +0000 (GMT)
Received: from [10.2.3.4] (unknown [95.83.250.203]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 560A2BE4C; Tue, 10 Dec 2013 08:59:27 +0000 (GMT)
User-Agent: K-9 Mail for Android
In-Reply-To: 
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Stephen Farrell 
Date: Tue, 10 Dec 2013 08:59:23 +0000
To: "Joseph Salowey (jsalowey)" , "" 
Message-ID: <7e7fa1fa-f889-4f3a-907d-670bb218d952@email.android.com>
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 08:59:39 -0000

Hi Joe

Wouid it be reasonable to add a "better privacy" goal for the tls 1.3 work? 

Ta
S


"Joseph Salowey (jsalowey)"  wrote:
>Updated Charter text based on the discussion so far is below.  Changes:
>
>
>1. Fixed typos 
>2. Third bullet to "Update record payload protection cryptographic
>mechanisms and algorithms to address known weaknesses
>in the CBC block cipher modes and to replace RC4."
>
>Thanks,
>
>Joe
>
>The TLS (Transport Layer Security) working group was
>established in 1996 to standardize a 'transport layer'
>security protocol.  The basis for the work was SSL
>(Secure Socket Layer) v3.0.  The TLS working group has
>completed a series of specifications that describe the
>TLS protocol v1.0, v1.1, and v1.2 and DTLS
>(Datagram TLS) v1.2 as well as extensions to the
>protocols and ciphersuites.
>
>The primary purpose of the working group is to develop
>(D)TLS v1.3.  Some of the main design goals are as follows,
>in no particular order:
>
>o Develop a mode that encrypts as much of the handshake as
>is possible to reduce the amount of observable data to
>both passive and active attackers.
>
>o Develop modes to reduce handshake latency, which primarily
>support HTTP-based applications, aiming for one roundtrip
>for a full handshake and one or zero roundtrip for repeated
>handshakes.
>
>o Update record payload protection cryptographic
>mechanisms and algorithms to address known weaknesses
>in the CBC block cipher modes and to replace RC4.
>
>o Reevaluate handshake contents, e.g.,: Is time needed in
>client hello?  Should signature in server key exchange
>cover entire handshake?  Are bigger randoms required?
>Should there be distinct cipher list for each version?
>
>A secondary purpose is to maintain previous version of
>the (D)TLS protocols as well as to specify the use of
>(D)TLS, recommendations for use of (D)TLS, extensions to
>(D)TLS, and cipher suites.  However, changes or additions
>to older versions of (D)TLS whether via extensions or
>ciphersuites are discouraged and require significant
>justification to be taken on as work items.
>
>With these objectives in mind, the TLS WG will also place a priority
>in minimizing gratuitous changes to TLS.
>
>Milestone/Dates:
>
>201311 - Out-of-Band Public Key Validation for TLS to IESG
>201401 - Secure Password Ciphersuites for TLS to IESG
>201404 - TLS ALPN (Application Layer Protocol Negotiation)
>      Extension to IESG
>201411 - (D)TLS 1.3 to IESG
>_______________________________________________
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls



From synp71@live.com  Tue Dec 10 01:24:50 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBE11ADBD1 for ; Tue, 10 Dec 2013 01:24:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=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 24pL9YcZNFCs for ; Tue, 10 Dec 2013 01:24:48 -0800 (PST)
Received: from blu0-omc3-s3.blu0.hotmail.com (blu0-omc3-s3.blu0.hotmail.com [65.55.116.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEFA1AD8D8 for ; Tue, 10 Dec 2013 01:24:48 -0800 (PST)
Received: from BLU0-SMTP174 ([65.55.116.72]) by blu0-omc3-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 10 Dec 2013 01:24:43 -0800
X-TMN: [Eu2sPoIS+vv2KTsvmNVRblPTtpOJkKGW]
X-Originating-Email: [synp71@live.com]
Message-ID: 
Received: from ynir-MBA.local ([194.29.32.131]) by BLU0-SMTP174.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 10 Dec 2013 01:24:41 -0800
Date: Tue, 10 Dec 2013 11:24:37 +0200
From: Yoav Nir 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Stephen Farrell ,  "Joseph Salowey (jsalowey)" , "" 
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>  <7e7fa1fa-f889-4f3a-907d-670bb218d952@email.android.com>
In-Reply-To: <7e7fa1fa-f889-4f3a-907d-670bb218d952@email.android.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040703080705070102080307"
X-OriginalArrivalTime: 10 Dec 2013 09:24:41.0715 (UTC) FILETIME=[A7EFAC30:01CEF589]
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 09:24:50 -0000

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

Hi Stephen

I suggest "better confidentiality". "Privacy" applies to humans, not=20
machines. I don't think it's appropriate for a machine-2-machine=20
protocol like TLS.

On 10/12/13 10:59 AM, Stephen Farrell wrote:
> Hi Joe
>
> Wouid it be reasonable to add a "better privacy" goal for the tls 1.3 w=
ork?
>
> Ta
> S
>
>
> "Joseph Salowey (jsalowey)"  wrote:
>> Updated Charter text based on the discussion so far is below.  Changes=
:
>>
>>
>> 1. Fixed typos
>> 2. Third bullet to "Update record payload protection cryptographic
>> mechanisms and algorithms to address known weaknesses
>> in the CBC block cipher modes and to replace RC4."
>>
>> Thanks,
>>
>> Joe
>>
>> The TLS (Transport Layer Security) working group was
>> established in 1996 to standardize a 'transport layer'
>> security protocol.  The basis for the work was SSL
>> (Secure Socket Layer) v3.0.  The TLS working group has
>> completed a series of specifications that describe the
>> TLS protocol v1.0, v1.1, and v1.2 and DTLS
>> (Datagram TLS) v1.2 as well as extensions to the
>> protocols and ciphersuites.
>>
>> The primary purpose of the working group is to develop
>> (D)TLS v1.3.  Some of the main design goals are as follows,
>> in no particular order:
>>
>> o Develop a mode that encrypts as much of the handshake as
>> is possible to reduce the amount of observable data to
>> both passive and active attackers.
>>
>> o Develop modes to reduce handshake latency, which primarily
>> support HTTP-based applications, aiming for one roundtrip
>> for a full handshake and one or zero roundtrip for repeated
>> handshakes.
>>
>> o Update record payload protection cryptographic
>> mechanisms and algorithms to address known weaknesses
>> in the CBC block cipher modes and to replace RC4.
>>
>> o Reevaluate handshake contents, e.g.,: Is time needed in
>> client hello?  Should signature in server key exchange
>> cover entire handshake?  Are bigger randoms required?
>> Should there be distinct cipher list for each version?
>>
>> A secondary purpose is to maintain previous version of
>> the (D)TLS protocols as well as to specify the use of
>> (D)TLS, recommendations for use of (D)TLS, extensions to
>> (D)TLS, and cipher suites.  However, changes or additions
>> to older versions of (D)TLS whether via extensions or
>> ciphersuites are discouraged and require significant
>> justification to be taken on as work items.
>>
>> With these objectives in mind, the TLS WG will also place a priority
>> in minimizing gratuitous changes to TLS.
>>
>> Milestone/Dates:
>>
>> 201311 - Out-of-Band Public Key Validation for TLS to IESG
>> 201401 - Secure Password Ciphersuites for TLS to IESG
>> 201404 - TLS ALPN (Application Layer Protocol Negotiation)
>>       Extension to IESG
>> 201411 - (D)TLS 1.3 to IESG
>> _______________________________________________
>> 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



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO4zCC
BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE
BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w
NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC
VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l
dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO
LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN
NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy
lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq
vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6
hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu
9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G
A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/
BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny
bC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEB
BCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B
AQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH
kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf
sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5
lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJx
ggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRow
ggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT
AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRo
ZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t
MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1h
aWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp
b24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFAGpDM
J1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq1Gdv
IBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg7SQf
Oq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWSD//g
sWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUswggFH
MB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvGeGNk
J8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE
CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29t
L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYB
BQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRk
VHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu
Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1
G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA
8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD
8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxH
maWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU
0rD+83X5f27nMIIFIDCCBAigAwIBAgIRAJLy3rLPGBD9qh6TW+ZG9DowDQYJKoZIhvcNAQEF
BQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV
BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P
RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMxMTE3
MDAwMDAwWhcNMTQxMTE3MjM1OTU5WjAgMR4wHAYJKoZIhvcNAQkBFg9zeW5wNzFAbGl2ZS5j
b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCow0TXP0M95fIMY0Fsd3xpZj55
m1mkkKhUWLjVtQcd57MyVmBZNQkAmxp9PrzqdHw5eIIBn1EI9foIoynEnUSZzv6pIEXAqdYu
xBH0AdvjoPCzWb9uYrqBtbmxnLh9k9ox1pVJG4hit6WEpK+LZ7uvLj5GUWMdmzghC/+fVEZS
W8U62xlhd8Hq8ded9bfqjM4psDgqUubjcCkMIUnkD9yuXhzfzwF0wwtD66vXrUe8T4/m6XHO
iIqvvVMjzYyKrdLE7zuPyDcDjkxLCCdi2j4c44anq8Pj/yEh5JGU0XSKSfwm2m0UDHj7P/6u
B74JwiAyMtqWzdQBHVOphHKDI0ZTAgMBAAGjggHfMIIB2zAfBgNVHSMEGDAWgBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUq+f5Y55gheJJpWtJDEPf6j2uzhQwDgYDVR0PAQH/
BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC
MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG
AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBI
hkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu
ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6
Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJl
RW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAaBgNV
HREEEzARgQ9zeW5wNzFAbGl2ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBACRvTZSZMhI7HrJr
jTpnm5FZXyYwJYVhhc643/94hv8pxAQzIY6vH+BlVwmG4Z0Dt6vWYwaUUYdGmvlH0bti8aql
JPe4fUgTxbDlTldhOYfISl3ky9+4CEPg4QvX6tOGIusOrvaIszGUIdvKHzvYM4ZapdTxyFCt
oe1RXq/17ifvIklgmuh+QcB1xNBmE3lBNj+Vy8xLvsAQlqf9ZAIcBNL2yQGCaBcr6XoR24/D
oCNCTAOCR/J2nN/okuGsEF+kvxP/BCPBnDph9coFLNOEwR4ZataT6H4vq0fwGxm5SROTDYis
SUTKc+YYKY2RllEwOxX1NZUSmISuGKrGhr2aCaUxggQcMIIEGAIBATCBqTCBkzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa
MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0
aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJLy3rLPGBD9qh6TW+ZG9DowCQYF
Kw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTMxMjEwMDkyNDM3WjAjBgkqhkiG9w0BCQQxFgQU1MYCnsUdIfSZbP2/4PrsadvtxnQwbAYJ
KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G
CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB
ugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl
ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBAhEAkvLess8YEP2qHpNb5kb0OjCBvAYLKoZIhvcNAQkQAgsxgayggakwgZMxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCS8t6yzxgQ/aoek1vmRvQ6
MA0GCSqGSIb3DQEBAQUABIIBAHdfzEiTkXvjDnOlasOLuAC1QZ/mqTRm685fPbfZ8nhFgn4U
iawz21Q2P0PbbcInne6DKeAgeVG2a1XkCjqSGywOGwKtg6g/mtWzrxzMoliu+u42ptxtChe/
RASD5f9U1QGrti4ILcqkLMefLwn7Ku2Js7MG/bmaXvOIQJBRMCCEnLlnp64K1eQHnOjDiORp
xvDGQeNC4uUvbxj1JJLr7KySXiVDw2bMjA4MrjAi+khEXyK0lTLds85ie9Nkbpz/5DKr0EWl
B2OjGFrOIx6Bfck6d46zegqHZqxAskT1jSYJxwt43aXtYL5LC/JowIAQ2FpiarAuLGPkLob7
CEKMYS4AAAAAAAA=
--------------ms040703080705070102080307--

From stephen.farrell@cs.tcd.ie  Tue Dec 10 02:14:22 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331771A1F3D for ; Tue, 10 Dec 2013 02:14:22 -0800 (PST)
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, RP_MATCHES_RCVD=-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 xrkVyVf1ECmA for ; Tue, 10 Dec 2013 02:14:13 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 789EC1AD944 for ; Tue, 10 Dec 2013 02:14:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4A420BE5D; Tue, 10 Dec 2013 10:14:07 +0000 (GMT)
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 fAf0L+w4sprp; Tue, 10 Dec 2013 10:14:07 +0000 (GMT)
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 07B22BE54; Tue, 10 Dec 2013 10:14:07 +0000 (GMT)
Message-ID: <52A6E96F.1080808@cs.tcd.ie>
Date: Tue, 10 Dec 2013 10:14:07 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Yoav Nir ,  "Joseph Salowey (jsalowey)" , "" 
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>  <7e7fa1fa-f889-4f3a-907d-670bb218d952@email.android.com> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 10:14:22 -0000

On 12/10/2013 09:24 AM, Yoav Nir wrote:
> Hi Stephen
> 
> I suggest "better confidentiality". "Privacy" applies to humans, not 
> machines. I don't think it's appropriate for a machine-2-machine 
> protocol like TLS.

A reasonable point. However by privacy I was also trying to
include any reasonable steps that can be taken e.g. to make
traffic analysis harder, without implying that that would
be higher priority than e.g. performance though. For example
Alfredo's ideas on padding (or similar) could be built in
to the TLS1.3 application data protection and that could
be well worth while.

There could also be aspects related to how identifying
different protocol elements might be, where different design
decisions (with about the same costs) could be made if the
WG does or doesn't consider privacy.

I'd have no objection if the charter didn't use the term
privacy but it seems like a useful shorthand to save having to
try break it out into the various reasonable bits that could
be done here.

But yeah maybe it'd be better qualified e.g. to something
like "The WG will consider the privacy implications of
TLS1.3 and where possible (balancing with other requirements)
will aim to make TLS1.3 more privacy-friendly, e.g. via more
consistent application traffic padding, more considered use
of long term identifying values, etc."

To be clear: I'm not asking that TLS1.3 become Tor:-)

S.

> 
> On 10/12/13 10:59 AM, Stephen Farrell wrote:
>> Hi Joe
>> 
>> Wouid it be reasonable to add a "better privacy" goal for the tls
>> 1.3 work?
>> 
>> Ta S
>> 
>> 
>> "Joseph Salowey (jsalowey)"  wrote:
>>> Updated Charter text based on the discussion so far is below.
>>> Changes:
>>> 
>>> 
>>> 1. Fixed typos 2. Third bullet to "Update record payload
>>> protection cryptographic mechanisms and algorithms to address
>>> known weaknesses in the CBC block cipher modes and to replace
>>> RC4."
>>> 
>>> Thanks,
>>> 
>>> Joe
>>> 
>>> The TLS (Transport Layer Security) working group was established
>>> in 1996 to standardize a 'transport layer' security protocol.
>>> The basis for the work was SSL (Secure Socket Layer) v3.0.  The
>>> TLS working group has completed a series of specifications that
>>> describe the TLS protocol v1.0, v1.1, and v1.2 and DTLS (Datagram
>>> TLS) v1.2 as well as extensions to the protocols and
>>> ciphersuites.
>>> 
>>> The primary purpose of the working group is to develop (D)TLS
>>> v1.3.  Some of the main design goals are as follows, in no
>>> particular order:
>>> 
>>> o Develop a mode that encrypts as much of the handshake as is
>>> possible to reduce the amount of observable data to both passive
>>> and active attackers.
>>> 
>>> o Develop modes to reduce handshake latency, which primarily 
>>> support HTTP-based applications, aiming for one roundtrip for a
>>> full handshake and one or zero roundtrip for repeated 
>>> handshakes.
>>> 
>>> o Update record payload protection cryptographic mechanisms and
>>> algorithms to address known weaknesses in the CBC block cipher
>>> modes and to replace RC4.
>>> 
>>> o Reevaluate handshake contents, e.g.,: Is time needed in client
>>> hello?  Should signature in server key exchange cover entire
>>> handshake?  Are bigger randoms required? Should there be distinct
>>> cipher list for each version?
>>> 
>>> A secondary purpose is to maintain previous version of the (D)TLS
>>> protocols as well as to specify the use of (D)TLS,
>>> recommendations for use of (D)TLS, extensions to (D)TLS, and
>>> cipher suites.  However, changes or additions to older versions
>>> of (D)TLS whether via extensions or ciphersuites are discouraged
>>> and require significant justification to be taken on as work
>>> items.
>>> 
>>> With these objectives in mind, the TLS WG will also place a
>>> priority in minimizing gratuitous changes to TLS.
>>> 
>>> Milestone/Dates:
>>> 
>>> 201311 - Out-of-Band Public Key Validation for TLS to IESG 201401
>>> - Secure Password Ciphersuites for TLS to IESG 201404 - TLS ALPN
>>> (Application Layer Protocol Negotiation) Extension to IESG 201411
>>> - (D)TLS 1.3 to IESG 
>>> _______________________________________________ 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 skyper@thc.org  Tue Dec 10 08:45:57 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DD01AE0F6 for ; Tue, 10 Dec 2013 08:45:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.357
X-Spam-Level: 
X-Spam-Status: No, score=-0.357 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, MISSING_HEADERS=1.021, 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 csFb8Lgozw2D for ; Tue, 10 Dec 2013 08:45:56 -0800 (PST)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 141BC1ADFA3 for ; Tue, 10 Dec 2013 08:45:55 -0800 (PST)
Received: by mail-ie0-f170.google.com with SMTP id qd12so9061435ieb.1 for ; Tue, 10 Dec 2013 08:45:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=exj9E4SY9wWyb+R1IubXR+cY65fvH/91egd7ESBXk5Y=; b=CsMPTs3a/pzYp3gvsVUhQefFbFtv19pAI/iwkBZdoHVpwgDmPufLCcNreGM72CwUNV c87YpjmCZ4aF1qIKkl/EVPOAH64i+8Kg3Woab/VYoUjEiEIcz2rXRNLkxtGdtn/iazK/ wauOSDbA9YZ1kl3vSG2dxRpdRnBwaS+t1G+JU=
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:cc:content-type; bh=exj9E4SY9wWyb+R1IubXR+cY65fvH/91egd7ESBXk5Y=; b=D8mESfY/jSLvWBapGgEI33MkeBCPVuaV1zPNKly2awNpOwqyDBgtFCNKtDfDIzx1Ba +VabP5UbTkrtdCxIPVIAaewEOalQJf1neB1ZPWthH19eJlAFNgpm+BBQKxzqOTr4SkqE Kd/2M+3DwDY6S/YzFeECpb7+8WnO7JKbicggpqIPS7hmmwyrmCFxjRe4J10dnag3Cd98 KY7CGgfeMdnvbokw9ob4b0oKzsUK3VfKR6JZqeQi2SOKxCngy5QAK+4CzWnNUbWLxhJu Ch3M6IH8mgZlpHMgFF5gcBlNAhDHJeiDOkDEqk59Rzxl8YrKI+imUp1MU9zxlJvQV0tn pWlQ==
X-Gm-Message-State: ALoCoQnNhZ6dnWGhbml4n7lxBRCZGIoL2XAIeTZak83QDQrrj150LClEcF4pRcyo1W8QuJL66SVC
MIME-Version: 1.0
X-Received: by 10.50.136.201 with SMTP id qc9mr19734078igb.11.1386693950605; Tue, 10 Dec 2013 08:45:50 -0800 (PST)
Received: by 10.64.9.41 with HTTP; Tue, 10 Dec 2013 08:45:50 -0800 (PST)
X-Originating-IP: [31.55.30.202]
In-Reply-To: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com>
Date: Tue, 10 Dec 2013 16:45:50 +0000
Message-ID: 
From: Ralf Skyper Kaiser 
Cc: "" 
Content-Type: multipart/alternative; boundary=089e01229ed856f53004ed30d84b
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 16:45:57 -0000

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

Hi,

I only joined the conversation recently. Had a quick read of
http://tools.ietf.org/html/draft-ietf-tls-pwd-02 and have a question:

In a scenario where multiple users use the same password (group password):

What prevents a user (who knows the password) to impersonating the server
and mount a MITM between another user and the real server?


thanks & regards,

ralf



On Fri, Nov 8, 2013 at 1:11 AM, Joseph Salowey (jsalowey) <
jsalowey@cisco.com> wrote:

> This is the beginning of the working group last call for
>  draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for TLS-PWD
> has been reviewed by the IRTF CFRG group with satisfactory results.  The
> document needs particular attention paid to the integration of this
> mechanism into the TLS protocol.   Please send comments to the TLS list by
> December 2, 2013.
>
> - Joe
> (For the TLS chairs)
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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




On Fri, Nov 8, 2013 at 1:11 AM, Joseph Salowey (jsalowey) <jsalowey@cisc=
o.com> wrote:


This is the beginning of the working group l=
ast call for =A0draft-ietf-tls-pwd-01. =A0 The underlying cryptographic pro=
tocol for TLS-PWD has been reviewed by the IRTF CFRG group with satisfactor=
y results. =A0The document needs particular attention paid to the integrati=
on of this mechanism into the TLS protocol. =A0 Please send comments to the=
 TLS list by December 2, 2013.




- Joe

(For the TLS chairs)

_______________________________________________

TLS mailing list

TLS@ietf.org

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





--089e01229ed856f53004ed30d84b--

From trevp@trevp.net  Tue Dec 10 09:01:43 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEB11AE136 for ; Tue, 10 Dec 2013 09:01:43 -0800 (PST)
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 PhU2pPlfS9Y0 for ; Tue, 10 Dec 2013 09:01:41 -0800 (PST)
Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id 702431ADF74 for ; Tue, 10 Dec 2013 09:01:41 -0800 (PST)
Received: by mail-we0-f175.google.com with SMTP id t60so5224252wes.20 for ; Tue, 10 Dec 2013 09:01:35 -0800 (PST)
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=oA5F7MIJKXpYa9lOZ+ZukccAq0tJQLi8wzL4i8MoMYg=; b=Za//oCT5b0sUxufObzi/MTm6Pdqx0Tn8m5BxOHveFr1CHr0wjwwITxI+GMhfz6ZEtl kMzxHrB0e+pfqxyAGpwzEp421VZFimP3UlcDg7bkEhetVQlmo80F0fUavFgs1wrqkMyD hVChL6xtXXknnRyi369NMOWEVnDC7sgUN15S48BtD7SM9Z/akdL3Q3LrfYKmROnjgi10 O0PF2D1RQxrmN0/aiLAIYu7t7LACul/3TJfcgIWsi8KIG1xMD3kUIFJYnAJNa9mWstdt k4FfUz9QSCf6QC36iD1DU6MEBLdmlfhdAS0iDYsS76ZxmZAZXL6qv0GXBWniN1UcW1Kz oMQg==
X-Gm-Message-State: ALoCoQkZkakP0JzzYvgJM4pa8IzMF7GdXKQkjJy9eWu5hjRMnd4hz96d64eN7Bnmq69ix8o5YFNQ
MIME-Version: 1.0
X-Received: by 10.194.2.108 with SMTP id 12mr3113617wjt.64.1386694895238; Tue, 10 Dec 2013 09:01:35 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Tue, 10 Dec 2013 09:01:35 -0800 (PST)
X-Originating-IP: [199.83.223.81]
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> 
Date: Tue, 10 Dec 2013 09:01:35 -0800
Message-ID: 
From: Trevor Perrin 
To: Ralf Skyper Kaiser 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 17:01:43 -0000

On Tue, Dec 10, 2013 at 8:45 AM, Ralf Skyper Kaiser  wrote:
> Hi,
>
> I only joined the conversation recently. Had a quick read of
> http://tools.ietf.org/html/draft-ietf-tls-pwd-02 and have a question:
>
> In a scenario where multiple users use the same password (group password):
>
> What prevents a user (who knows the password) to impersonating the server
> and mount a MITM between another user and the real server?

Hi Ralf,

I believe that's possible.

In the TLS PAKE described in RFC 5054 (TLS/SRP), the server may
additionally be authenticated via a server certificate.


Trevor

From martin.thomson@gmail.com  Tue Dec 10 09:03:15 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BB81AE20D for ; Tue, 10 Dec 2013 09:03:15 -0800 (PST)
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 4qqCtaUwyfAk for ; Tue, 10 Dec 2013 09:03:13 -0800 (PST)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBCE1AE1F9 for ; Tue, 10 Dec 2013 09:03:13 -0800 (PST)
Received: by mail-we0-f180.google.com with SMTP id t61so5329376wes.11 for ; Tue, 10 Dec 2013 09:03:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E0fScMPgurwtkRMgzjz11TkEwQdIaKtlB5iT0bfk4bc=; b=DHtHqk8i9DYtFbni2yLK5nAv6WA/eWjhzZ+F2LYbgzYHHvKFdNK3X/Zn/h3t6zHyHl 3o3usTW1YLyYDm3SyHMzptA7t2OJInS0sv4lvQVo8l+hvpFbrzNG05sd0zEdCp+r3KTl xAd2UntdWRJ+46mcUqlJv273ukIkOVy8cQ51TQJ55EiPOwp8G+dbgf9t0eCxeyOfn7Z/ srGaUAVjfe2cEweRNsurb2Z4aIb/ksevwvEAbSErCYmWP/z21Uu0fnfs4+nzBjtnwfHI +rraiU9v7j+ZdRriZHA4O7k0XB1TQ4y5mvkJzoDhn3XL10vXbGsB6/i5o6tjd5Mys4CD p5Aw==
MIME-Version: 1.0
X-Received: by 10.180.10.135 with SMTP id i7mr20202412wib.1.1386694987713; Tue, 10 Dec 2013 09:03:07 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Tue, 10 Dec 2013 09:03:07 -0800 (PST)
In-Reply-To: 
References:   
Date: Tue, 10 Dec 2013 09:03:07 -0800
Message-ID: 
From: Martin Thomson 
To: Brian Smith 
Content-Type: text/plain; charset=UTF-8
Cc: Peter Gutmann , "" 
Subject: Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 17:03:15 -0000

On 9 December 2013 18:15, Brian Smith  wrote:
> If the server really doesn't care about the security or privacy
> properties of a resource, then it wouldn't implement opportunistic
> encryption in the first place, unless it was doing so purely as a
> compatibility hack.

I don't know that hack is the right word here.

One of the options that is being considered for HTTP/2.0 is the
mandatory implementation of unauthenticated TLS for http: URIs.  If
that were the case, all that a server would have to do is upgrade
their stack.  That sets a pretty low bar.

> we'd say that the client MUST NOT advertise
> the http2-tls-relaxed ALPN token, in order to avoid tipping off any
> MitM that the connection will be unauthenticated.

Yes, but that isn't the reason I'd use for it.  The reason is that
it's not necessary.  It's got absolutely nothing to do with tipping
anybody off.

From hannes.tschofenig@gmx.net  Tue Dec 10 12:46:55 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112BC1AE1CD for ; Tue, 10 Dec 2013 12:46:55 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 qBRxVRR5qHTc for ; Tue, 10 Dec 2013 12:46:53 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 425C41AE0D0 for ; Tue, 10 Dec 2013 12:46:52 -0800 (PST)
Received: from [192.168.10.140] ([2.102.217.110]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LfC4q-1VFAIn3Ysq-00okAp for ; Tue, 10 Dec 2013 21:46:46 +0100
Message-ID: <52A77DB4.7020501@gmx.net>
Date: Tue, 10 Dec 2013 20:46:44 +0000
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Brian Smith , "" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:SbxoF3ZikdUQejf/eRd4PH+RDc76dxl5chpWwpZ3mVRD+IcD8LB Y+8NdlAtLq8cjrIf1qhX6YdOdMx95NwCTWRnNly0ZmAT+H+TDvIhrO9GSA/DfbhTDDDZphS Xg/bSLEJJokM7kIaL7/NPI6ocAZnu4EWZ8NTwpUjKSRT96u/l2Uodmuzga/e5SkPPASy3Rb 3Mc8p/KY3Mki3nIVy8nBg==
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 20:46:55 -0000

On 12/09/2013 03:22 PM, Brian Smith wrote:
> I think we should re-evaluate whether we
> still have consensus on moving forward with recommending ALPN as the
> protocol negotiation mechanism to be used in TLS and specifically in
> HTTP/2.

+1

I was in the room and I recall the discussions. I went to the microphone
and expressed my excitement about the fact that privacy related topics
where discussed in the TLS working group (given that privacy wasn't an
issue previously) and the response was "This has nothing to do with
privacy.".

Luckily we know much better now (or at least some people do).

Ciao
Hannes


From tom@ritter.vg  Tue Dec 10 13:40:52 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A847B1AE0FE for ; Tue, 10 Dec 2013 13:40:52 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 75AOTcRBtb8Z for ; Tue, 10 Dec 2013 13:40:51 -0800 (PST)
Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 757AC1AE04B for ; Tue, 10 Dec 2013 13:40:51 -0800 (PST)
Received: by mail-pb0-f50.google.com with SMTP id rr13so8515895pbb.23 for ; Tue, 10 Dec 2013 13:40:46 -0800 (PST)
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=h02Yj0ppXn7+lpvMfLlZM6qBf1lOYoHKQXoVlTbmvjI=; b=wiYSyhtC1q5wqi8elz3FrpMsw5YtSwIfkWjyRxx3lgd0+jNC6Ag3tcM+iS/TsGC7Mw ziC8/NZkSS36F2mzC4e6wwaMfuoB7/Xt+2kb0Cc8yQAzcM2RosoRWoW0z2mOrQa5j9Qf dUgYne+7dWFIJmC+HLLEMBxq050F0Wke4Tlj0=
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=h02Yj0ppXn7+lpvMfLlZM6qBf1lOYoHKQXoVlTbmvjI=; b=aQvblLC9AxDHdX7oiiUosgaG//eoQ+GeO2Rjth64kPGWB2lBOAnq1UA8n0gilXLsSB qQOS8TeoLz4Xyte4YUfGFHj6xK2z6bfQj4PjWoVuh4MMmY3yR0SL20ZhS4Q9i8gynj5+ EzqplzwP8XqFcdFcZAHTRV2cA0mdxzK4LletiySpLSHvW+20WqWy3mHYjuV0eWuKuELR ovuYvT3mkq8v/5f1jlLxuMdx5yogG7gPs/LYAB8Ud338p5M9Zhd1STGJHgz7Tak/QUJz fZXPKFclU4JREPygVShZboEjLsFmY1aWxvbO4NzHqOypeuAiv2Z8a1kPgLIe7KzNNuHO uMBA==
X-Gm-Message-State: ALoCoQmuBJwT7rvY8Zuh5Enjm9C23XYYuhadkTUz53KxafH5B2oJ/BNuM+4B9dhR+A+pHdJuNdBK
X-Received: by 10.68.189.197 with SMTP id gk5mr30006585pbc.37.1386711646256; Tue, 10 Dec 2013 13:40:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.169.193 with HTTP; Tue, 10 Dec 2013 13:40:26 -0800 (PST)
In-Reply-To: <52A77DB4.7020501@gmx.net>
References:  <52A77DB4.7020501@gmx.net>
From: Tom Ritter 
Date: Tue, 10 Dec 2013 16:40:26 -0500
Message-ID: 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=e89a8ff1cc7a14da0504ed34f716
Cc: "" 
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 21:40:52 -0000

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

On 10 December 2013 15:46, Hannes Tschofenig wrote:

>
> On 12/09/2013 03:22 PM, Brian Smith wrote:
> > I think we should re-evaluate whether we
> > still have consensus on moving forward with recommending ALPN as the
> > protocol negotiation mechanism to be used in TLS and specifically in
> > HTTP/2.
>
> +1
>

+1

I raised my preference for NPN over ALPN (and for generic post-CCS
extensions) last time around on the mailing list, and still keep that
preference.

-tom

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


On 1=
0 December 2013 15:46, Hannes Tschofenig <hannes.tschofenig@gmx.ne=
t> wrote:





On 12/09/2013 03:22 PM, Brian Smith wrote:

> I think we should re-evaluate whether we

> still have consensus on moving forward with recommending ALPN as the
> protocol negotiation mechanism to be used in TLS and specifically in
> HTTP/2.




+1

+1

I =
raised my preference for NPN over ALPN (and for generic post-CCS extensions=
) last time around on the mailing list, and still keep that preference. =A0=
 =A0




-tom


--e89a8ff1cc7a14da0504ed34f716--

From dharkins@lounge.org  Tue Dec 10 14:07:00 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7071AE08B for ; Tue, 10 Dec 2013 14:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 h52TWCQVzhE3 for ; Tue, 10 Dec 2013 14:06:58 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id DF3A41AE06D for ; Tue, 10 Dec 2013 14:06:58 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6DA0E10224008; Tue, 10 Dec 2013 14:06:53 -0800 (PST)
Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 10 Dec 2013 14:06:53 -0800 (PST)
Message-ID: <7a5a264b029777f3c0b2d2f97a362463.squirrel@www.trepanning.net>
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> 
Date: Tue, 10 Dec 2013 14:06:53 -0800 (PST)
From: "Dan Harkins" 
To: "Ralf Skyper Kaiser" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 22:07:00 -0000

  Hi Ralf,

On Tue, December 10, 2013 8:45 am, Ralf Skyper Kaiser wrote:
> Hi,
>
> I only joined the conversation recently. Had a quick read of
> http://tools.ietf.org/html/draft-ietf-tls-pwd-02 and have a question:
>
> In a scenario where multiple users use the same password (group password):
>
> What prevents a user (who knows the password) to impersonating the server
> and mount a MITM between another user and the real server?

  Nothing prevents that. This protocol is not designed to support group
passwords. The password credential is assumed to be shared between
the client and the server only.

  regards,

  Dan.



From stephen.farrell@cs.tcd.ie  Tue Dec 10 14:19:34 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198B31AE0FA for ; Tue, 10 Dec 2013 14:19:34 -0800 (PST)
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, RP_MATCHES_RCVD=-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 KFtbIOCZypHG for ; Tue, 10 Dec 2013 14:19:31 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7121AE0F3 for ; Tue, 10 Dec 2013 14:19:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 857ADBE60; Tue, 10 Dec 2013 22:19:23 +0000 (GMT)
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 QW16bDBTEKMk; Tue, 10 Dec 2013 22:19:21 +0000 (GMT)
Received: from [10.87.48.12] (unknown [86.42.21.29]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 692ADBE5D; Tue, 10 Dec 2013 22:19:21 +0000 (GMT)
Message-ID: <52A7935E.5020906@cs.tcd.ie>
Date: Tue, 10 Dec 2013 22:19:10 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Hannes Tschofenig ,  Brian Smith , "" 
References:  <52A77DB4.7020501@gmx.net>
In-Reply-To: <52A77DB4.7020501@gmx.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 22:19:34 -0000

On 12/10/2013 08:46 PM, Hannes Tschofenig wrote:
> 
> On 12/09/2013 03:22 PM, Brian Smith wrote:
>> I think we should re-evaluate whether we
>> still have consensus on moving forward with recommending ALPN as the
>> protocol negotiation mechanism to be used in TLS and specifically in
>> HTTP/2.
> 
> +1
> 
> I was in the room and I recall the discussions. I went to the microphone
> and expressed my excitement about the fact that privacy related topics
> where discussed in the TLS working group (given that privacy wasn't an
> issue previously) and the response was "This has nothing to do with
> privacy.".
> 
> Luckily we know much better now (or at least some people do).

(no hats as usual)

FWIW, I agree with you in general, but in this case the privacy
leak is non-existent if its only HTTP/1.1 vs HTTP/2.0 - since
the binary encoding and lack of head-of-line blocking in the
latter will give that game away anyway.

I'd say focusing on tls1.3 and any privacy gains there is better
than diverting effort to NPN to be honest.

S.

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

From trevp@trevp.net  Tue Dec 10 14:30:58 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178071AE225 for ; Tue, 10 Dec 2013 14:30:58 -0800 (PST)
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, LOTS_OF_MONEY=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 On1lq5InjP6j for ; Tue, 10 Dec 2013 14:30:54 -0800 (PST)
Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2E31AE1BB for ; Tue, 10 Dec 2013 14:30:54 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id u57so5656533wes.18 for ; Tue, 10 Dec 2013 14:30:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=um4+UYNy4sTsPv13IiAF31cKsele6iIz0Ibye3eRC7c=; b=fa+txElP6xnBZhmSHivrWkVIe/QUf4W0eOfe4M2vPZtHr0qf9a3W6ajh7w0o7wP8gZ JjUaLwWJdEfGbygOxTUppXhXAvMe0Um3MREOaG76UkC+Wm1HVNv9X8Y4/g6htCSxaE3G U6VN++sR58mge4fcra6ZM187rm885qZp+3Z8yWThgZAQia9v3XlUZKS1TiLo9G5mmTzS PxEKjuJpjNetThSec2QAV58yTLUmF3g29Y0q/pBJ2L/ui/VlJck0+LdVN9RounxkA/H9 40tatVLZKTgupohRxDDgx/y/Vun3/NgH/T7OYZR/HgP238+QmB8j+A6pDit6yygde7BZ he/g==
X-Gm-Message-State: ALoCoQmCkEmaSk8vftzy5JXRwBU242YfmMQkv7HMxGnof0QZxWQMw6fClEUvFEBW92J7fXnYEPML
MIME-Version: 1.0
X-Received: by 10.180.73.6 with SMTP id h6mr145087wiv.20.1386714648580; Tue, 10 Dec 2013 14:30:48 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Tue, 10 Dec 2013 14:30:48 -0800 (PST)
X-Originating-IP: [199.83.223.81]
Date: Tue, 10 Dec 2013 14:30:48 -0800
Message-ID: 
From: Trevor Perrin 
To: cfrg@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: [TLS] Review of Dragonfly PAKE
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 22:30:58 -0000

Dear CFRG (cc: TLS),

Here's a review of the Dragonfly Password-Authenticated Key Exchange (PAKE) from
draft-irtf-cfrg-dragonfly-02 [CFRGDRAFT].

Overview
----
The Dragonfly PAKE is built on SPEKE with an "obfuscation" applied to
the exchange of Diffie-Hellman values.  The obfuscation lacks formal
analysis and serves no obvious purpose, but may be an attempt to avoid
the SPEKE patent [IPSEC].  Dragonfly has security weaknesses due to
use of a variable-time algorithm to map a password to an EC point
[STRUIK], and lack of "augmented" PAKE properties.

Obfuscating the SPEKE DH exchange
----
SPEKE is an old and well-known PAKE [JABLON].  In SPEKE each party
uses a shared password to derive a Diffie-Hellman generator.  The
generator is then used for a Diffie-Hellman exchange.

SPEKE is patented until 2017 [SPEKEPATENT].  Alternatives without
current patents incude [DH-EKE] and [J-PAKE].  Alternatives with
royalty-free terms include [SRP] and [AUGPAKE].

Dragonfly uses the SPEKE approach but obfuscates the exchange of DH
values.  In particular, given:

  g : DH generator (calculated by hashing the password)
  a : Alice's DH private key

In SPEKE, Alice sends g^a.

In Dragonfly, Alice generates a mask m, and sends (a+m, g^-m).  Bob
uses these values and g to reconstruct g^a.  [ g^a = g^(a+m) * g^-m ]

This obfuscation adds computation and bandwidth costs.  It's not clear
whether it adds any security benefit.  It's not clear how Dragonfly's
security relates to SPEKE; whether the SPEKE security proof from
[MACKENZIE] still applies; or whether another security proof could be
created.

The Dragonfly author argues that the SPEKE patent only covers use of a
"password-based parameter" with a "known technique of unauthenticated
key distribution" [IPSEC], and thus does not apply to Dragonfly.

It's not obvious that this is true.  Particularly given expiry of the
Lucent EKE/DH-EKE patents [LUCENT], the Dragonfly IPR situation seems
less clear than some alternatives.


Sidechannel attack on mapping password to EC point
----
Mapping a password onto a Diffie-Hellman generator is easy for
Diffie-Hellman with safe primes, which are typically used with SPEKE.
For ECDH, the naive "try-and-increment" algorithm for mapping to a
point leaks timing information about its input ([BONEH], [ICART]).

Nonetheless, this algorithm might be acceptable provided its input is
fixed for a given password.  Unfortunately, Dragonfly recommends
mixing nonces with the password prior to "hunting-and-pecking".  This
enables a timing attack:

 * The attacker initiates many protocol runs, recording the time taken
by the server to produce each Commit message.  (Alternatively, the
attacker passively observes many protocol runs.)

 * Afterwards, for each offline password guess, the attacker predicts
how long the "hunting-and-pecking" algorithm would have taken for each
run.

 * For a successful guess, the predictions will be correlated with
recorded times.

Dragonfly attempts to reduce this timing leak by performing the
"hunting-and-pecking" loop a fixed number of times (at least 40 is
recommended).  Yet within each loop are conditional branches and
Legendre symbol / square-root algorithms, which are hard to implement
efficiently in constant time ([STRUIK], [ICART], [FIPS186-4]).

This attack is easily avoided by omitting nonces from the input to the
"hunting-and-pecking" loop.  However, variants of the attack may be
possible (e.g. using salt to attack the client).  Difficulties of this
sort are why PAKE schemes often avoid the EC setting.


Non-augmented protocol
-----
Unlike [SRP] and [AUGPAKE], Dragonfly is a "balanced" PAKE, not an
"augmented" one.  This means that a Dragonfly server stores values
that can be used directly to authenticate to that server.  In
contrast, an SRP or AugPAKE server stores verifiers which would have
to be attacked by password-cracking.


Conclusions
------------
The Dragonfly approach seems inferior to existing PAKE schemes due to:
 * Lack of formal security proofs or extensive cryptanalysis
 * An unclear IPR situation compared to alternatives
 * High computation cost due to "hunting-and-pecking" and "DH obfuscation"
 * Side-channel risks due to "hunting-and-pecking"
 * Non-augmented properties


Trevor


[CFRGDRAFT] http://tools.ietf.org/html/draft-irtf-cfrg-dragonfly-02
[IPSEC] http://www.ietf.org/mail-archive/web/ipsec/current/msg06323.html
[STRUIK]
  http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html
  http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html
  http://www.ietf.org/mail-archive/web/cfrg/current/msg03527.html
[JABLON]
  http://www.jablon.org/jab96.pdf
  http://www.jablon.org/jab97.pdf
[SPEKEPATENT]
  https://www.google.com/patents/US6226383
  https://www.google.com/patents/US6792533
[DH-EKE]
  http://www.cs.columbia.edu/~smb/papers/neke.ps
  http://eprint.iacr.org/2000/014.pdf
[J-PAKE] http://eprint.iacr.org/2010/190.pdf
[SRP]
  http://tools.ietf.org/html/rfc5054
  http://srp.stanford.edu/design.html
[AUGPAKE] https://eprint.iacr.org/2010/334.pdf
[MACKENZIE] https://eprint.iacr.org/2001/057.pdf
[LUCENT] http://www.ietf.org/mail-archive/web/tls/current/msg08191.html
[BONEH] http://cseweb.ucsd.edu/~hovav/dist/sigs.pdf
[ICART] http://www.iacr.org/archive/crypto2009/56770300/56770300.pdf
[FIPS186-4] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf

From hovav@eng.ucsd.edu  Tue Dec 10 14:57:43 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6605D1AE120 for ; Tue, 10 Dec 2013 14:57:43 -0800 (PST)
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 981nfHOTYsAh for ; Tue, 10 Dec 2013 14:57:42 -0800 (PST)
Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) by ietfa.amsl.com (Postfix) with ESMTP id C61631A1F1A for ; Tue, 10 Dec 2013 14:57:41 -0800 (PST)
Received: by mail-vb0-f48.google.com with SMTP id f13so1056346vbg.7 for ; Tue, 10 Dec 2013 14:57:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=Pd4vJ/6Mx9sT4EIXW5kF9OuT2exJiIx8JTg4tScitWE=; b=hJoSz5Y9bqgX5Kn8u6n2et50RTNQjc1htJ+VVNr46Y03yZLA2UeZ3kV5U866dOHFLi f5eoHSrQPv+SSHakdA4e/R0/b/p+iBddtsvETMPGmJxYRFGyaVQBZPwCA2fDgqxCgIE2 sVmJ7tpkxts8t1OgwYsV9YpIdEpW8b3JZOnXZme0u5KEVRk6PHm0auNyWW9mAK8fJGgN c7jTgw8Yis+QdWcvc0U5OKO5SqgJKI8JUC/Q8W5zg2mRQbUVVrHWc7QRrEnbkmWaBTbF wrbKB6RoLntPs00qS9gQlkNfMDdYmLR/yFm3SADSO7kdWfiS/Gzzu63QOS8bkuvk3HsW dXKg==
X-Gm-Message-State: ALoCoQknGvOUAdwO8OhCv6hVl9m8lOsjcDzYpVarExPwSeNkWcHNyUXtxe1SHTTmqkE6ad+LmYdM
X-Received: by 10.220.19.134 with SMTP id a6mr1083126vcb.36.1386716256332; Tue, 10 Dec 2013 14:57:36 -0800 (PST)
MIME-Version: 1.0
Sender: hovav@eng.ucsd.edu
Received: by 10.52.159.162 with HTTP; Tue, 10 Dec 2013 14:57:16 -0800 (PST)
In-Reply-To: 
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> 
From: Hovav Shacham 
Date: Tue, 10 Dec 2013 14:57:16 -0800
X-Google-Sender-Auth: Z_1WeLqQ6jS4xqymjLbxUyY8vTs
Message-ID: 
To: "" 
Content-Type: multipart/alternative; boundary=001a11c3ae1cdd060604ed360912
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 10 Dec 2013 22:57:43 -0000

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

On Mon, Dec 9, 2013 at 10:38 PM, Joseph Salowey (jsalowey) <
jsalowey@cisco.com> wrote:

> Updated Charter text based on the discussion so far is below.


I support this proposed charter, FWIW.

-hs.

--001a11c3ae1cdd060604ed360912
Content-Type: text/html; charset=ISO-8859-1


On Mon, Dec 9, 2013 at 10:38 PM, Joseph Salowey (jsalowey) <jsalowey@cisco.com> wrote:



Updated Charter text based on the discussion so far is below.

I support this proposed charter, FWIW.




-hs.


--001a11c3ae1cdd060604ed360912--

From dharkins@lounge.org  Tue Dec 10 17:35:59 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DAE1ADFDD; Tue, 10 Dec 2013 17:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.866
X-Spam-Level: 
X-Spam-Status: No, score=-3.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 dXDUkNQkSZO1; Tue, 10 Dec 2013 17:35:56 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9021D1ADED8; Tue, 10 Dec 2013 17:35:56 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 521CC10224008; Tue, 10 Dec 2013 17:35:51 -0800 (PST)
Received: from 50.197.170.142 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 10 Dec 2013 17:35:51 -0800 (PST)
Message-ID: <081a8a74fc0084dcff176b07a7502c93.squirrel@www.trepanning.net>
In-Reply-To: 
References: 
Date: Tue, 10 Dec 2013 17:35:51 -0800 (PST)
From: "Dan Harkins" 
To: "Trevor Perrin" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: cfrg@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Review of Dragonfly PAKE
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 01:36:00 -0000

  Hi Trevor,

On Tue, December 10, 2013 2:30 pm, Trevor Perrin wrote:
> Dear CFRG (cc: TLS),
>
> Here's a review of the Dragonfly Password-Authenticated Key Exchange
> (PAKE) from
> draft-irtf-cfrg-dragonfly-02 [CFRGDRAFT].
>
> Overview
> ----
> The Dragonfly PAKE is built on SPEKE with an "obfuscation" applied to
> the exchange of Diffie-Hellman values.

  I disagree with this over-simplification.

>                                                             The
obfuscation
lacks formal
> analysis and serves no obvious purpose, but may be an attempt to avoid
> the SPEKE patent [IPSEC].  Dragonfly has security weaknesses due to
> use of a variable-time algorithm to map a password to an EC point
> [STRUIK], and lack of "augmented" PAKE properties.

  What is a "weakness" from the point of view of an augmented PAKE
scheme is a benefit from the point of view of a balanced PAKE scheme.
Augmented PAKE schemes bind the password to a single domain
parameter set while balanced PAKE schemes allow for the domain
parameter set to be negotiated. This allows, for example, a domain
parameter set to be agreed upon that provides commensurate
security to the rest of the cipher suite with which it can be used.

  It makes little sense to negotiate a 256-bit or even a 128-bit
cipher or a hash algorithm with a 256-bit or 512-bit digest size
when the domain parameter set is fixed to a 1024-bit FFC group.
What makes sense is to allow for negotiation of a 4096-bit FFC
group or a 256-bit ECC group along with your AES-GCM-128
with key derivation using HMAC-256.

  Of course, you may disagree (in fact, I'll bet money on it). But
I hope you do not feel that your opinion is the only valid one. I
respect your opinion on the matter, I just don't know why you
fail to respect the opinion of anyone who has a different evaluation
of that cost-benefit equation.

  A balanced PAKE scheme in addition to the existing augmented
PAKE scheme offers choice. You want to restrict and prohibit
choice.

> Obfuscating the SPEKE DH exchange
> ----
> SPEKE is an old and well-known PAKE [JABLON].  In SPEKE each party
> uses a shared password to derive a Diffie-Hellman generator.  The
> generator is then used for a Diffie-Hellman exchange.
>
> SPEKE is patented until 2017 [SPEKEPATENT].  Alternatives without
> current patents incude [DH-EKE] and [J-PAKE].  Alternatives with
> royalty-free terms include [SRP] and [AUGPAKE].

  AugPAKE has particularly nasty terms as the license explicitly
states that the "royalty-free" license does not cover all the claims
in the patent yet it does not spell out exactly which ones are or
are not covered. If your legal council advises you accept such a
license I'd advise you get new legal council.

> Dragonfly uses the SPEKE approach but obfuscates the exchange of DH
> values.  In particular, given:
>
>   g : DH generator (calculated by hashing the password)
>   a : Alice's DH private key
>
> In SPEKE, Alice sends g^a.
>
> In Dragonfly, Alice generates a mask m, and sends (a+m, g^-m).  Bob
> uses these values and g to reconstruct g^a.  [ g^a = g^(a+m) * g^-m ]
>
> This obfuscation adds computation and bandwidth costs.  It's not clear
> whether it adds any security benefit.  It's not clear how Dragonfly's
> security relates to SPEKE; whether the SPEKE security proof from
> [MACKENZIE] still applies; or whether another security proof could be
> created.

  Apparently much is not clear to you. I will tell you that I do not believe
that sending (a+m, g^-m) with a password-derived g has any security
benefits over sending g^a with a password-derived g. Does that clear
anything up?

> The Dragonfly author argues that the SPEKE patent only covers use of a
> "password-based parameter" with a "known technique of unauthenticated
> key distribution" [IPSEC], and thus does not apply to Dragonfly.
>
> It's not obvious that this is true.

  That is truly a content-free statement, especially given the subject matter
(IPR). The reference you give goes to some lengths to explain the rationale
behind that statement. Sadly your response does not address any points
made in that reference, and, in fact, contributes nothing. Maybe this too is
not clear to you so let me give a brief attempt to make it more obvious:

  - if you replace the password-derived generator from SPEKE with the
     generator from the domain parameter set what do you have? You have
     the Diffie-Hellman key exchange, a "known technique of unauthenticated
     key distribution."

  - if you replace the password-derived generator from dragonfly with
     the generator from the domain parameter set what do you have? Well,
     whatever it is it is certainly not a "known technique of unauthenticated
     key distribution." I had never seen this technique of unauthenticated
     key distribution. If you have, please provide me with a reference from
     before 2007 or so.

>                                                      Particularly given
expiry of the
> Lucent EKE/DH-EKE patents [LUCENT], the Dragonfly IPR situation seems
> less clear than some alternatives.

  The existence of "alternatives" is really irrelevant to the subject of
your email-- a review of dragonfly. Yes there are numerous ways to skin
a cat. So what?

> Sidechannel attack on mapping password to EC point
> ----
> Mapping a password onto a Diffie-Hellman generator is easy for
> Diffie-Hellman with safe primes, which are typically used with SPEKE.
> For ECDH, the naive "try-and-increment" algorithm for mapping to a
> point leaks timing information about its input ([BONEH], [ICART]).
>
> Nonetheless, this algorithm might be acceptable provided its input is
> fixed for a given password.  Unfortunately, Dragonfly recommends
> mixing nonces with the password prior to "hunting-and-pecking".  This
> enables a timing attack:

  This has been discussed on both the TLS and CFRG lists already.

>  * The attacker initiates many protocol runs, recording the time taken
> by the server to produce each Commit message.  (Alternatively, the
> attacker passively observes many protocol runs.)
>
>  * Afterwards, for each offline password guess, the attacker predicts
> how long the "hunting-and-pecking" algorithm would have taken for each
> run.

  Except that the amount of time is hidden by a constant number of
loops through the hunting-and-pecking loop. Given that randomness
replaces the base once PE is obtained, it makes it all the more difficult
for the attacker to use any recorded time from a run of the protocol
or to make any prediction on the amount of time it would take.

>  * For a successful guess, the predictions will be correlated with
> recorded times.

  Which given the additional randomness will not correlate in a
way that allows the attacker to reduce the size of the pool from
which the password was chosen.

> Dragonfly attempts to reduce this timing leak by performing the
> "hunting-and-pecking" loop a fixed number of times (at least 40 is
> recommended).  Yet within each loop are conditional branches and
> Legendre symbol / square-root algorithms, which are hard to implement
> efficiently in constant time ([STRUIK], [ICART], [FIPS186-4]).

  It also adds randomness into the loop once PE is found, which
will be with probability 1 - (q/2p)^n, after n loops (where q is the
order of the domain parameter set and p is the prime).

  And that's why it continues to loop through a fixed number of times,
in order to hide the number of times it took to find the solution.

> This attack is easily avoided by omitting nonces from the input to the
> "hunting-and-pecking" loop.  However, variants of the attack may be
> possible (e.g. using salt to attack the client).  Difficulties of this
> sort are why PAKE schemes often avoid the EC setting.

  The current "hunting-and-pecking" text in draft-ietf-tls-pwd is
the result of a discussion with numerous people on a long thread on
the TLS list from an earlier version of the draft. Given that you have
obviously spent a considerable amount of time scouring through
numerous email lists that should be known to you. I'm not really sure
why you have waited until now to comment on it but I'm glad you have,
so let me ask:

  - what change would you like to see in the text and why? And,

  - if I accommodated your change would you support this draft?

> Non-augmented protocol
> -----
> Unlike [SRP] and [AUGPAKE], Dragonfly is a "balanced" PAKE, not an
> "augmented" one.  This means that a Dragonfly server stores values
> that can be used directly to authenticate to that server.  In
> contrast, an SRP or AugPAKE server stores verifiers which would have
> to be attacked by password-cracking.

  This is well-known and mentioned in the Security Considerations.
As mentioned above, the benefit to this cost is that the domain
parameter set is not fixed to a password. And, as I mentioned, while
you may not view that benefit as outweighing the cost, your opinion
is not the ultimate truth on the subject, other people may evaluate
that equation differently and just because they do does not mean
they're wrong.

  As I mentioned above, having a balanced PAKE protocol (dragonfly)
as well as an augmented PAKE protocol (SRP) allows for freedom of
choice. What you are advocating for is less choice, and in fact,
restricting everyone to what you would choose. That is a somewhat
arrogant position.

  I'm also not sure why you have become a cheerleader for AugPAKE,
especially given your previous statements about: 1) how nobody
wants any PAKE solution in TLS; 2) that we have SRP and that can
address the few people (in your mind) who want it; and, 3) how you
would be against any additional PAKE scheme in TLS. It's especially
bizarre given that AugPAKE offers nothing on top of what SRP already
offers.

> Conclusions
> ------------
> The Dragonfly approach seems inferior to existing PAKE schemes due to:
>  * Lack of formal security proofs or extensive cryptanalysis
>
>  * An unclear IPR situation compared to alternatives

  It is extremely clear; it's not patented. Would you would like me to give
you a "royalty-free" license to use an unpatented protocol? Would you like
it to include all of the claims in a patent that does not exist or would you
be OK with it if it excluded some claims in a patent that does not exist?

>  * High computation cost due to "hunting-and-pecking" and "DH obfuscation"
>  * Side-channel risks due to "hunting-and-pecking"
>  * Non-augmented properties

  Aside from the last one, which is your personal preference which has
really no bearing on the personal preferences of anyone else, what would
you like to see change in the draft?

  regards,

  Dan.

> Trevor
>
>
> [CFRGDRAFT] http://tools.ietf.org/html/draft-irtf-cfrg-dragonfly-02
> [IPSEC] http://www.ietf.org/mail-archive/web/ipsec/current/msg06323.html
> [STRUIK]
>   http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html
>   http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html
>   http://www.ietf.org/mail-archive/web/cfrg/current/msg03527.html
> [JABLON]
>   http://www.jablon.org/jab96.pdf
>   http://www.jablon.org/jab97.pdf
> [SPEKEPATENT]
>   https://www.google.com/patents/US6226383
>   https://www.google.com/patents/US6792533
> [DH-EKE]
>   http://www.cs.columbia.edu/~smb/papers/neke.ps
>   http://eprint.iacr.org/2000/014.pdf
> [J-PAKE] http://eprint.iacr.org/2010/190.pdf
> [SRP]
>   http://tools.ietf.org/html/rfc5054
>   http://srp.stanford.edu/design.html
> [AUGPAKE] https://eprint.iacr.org/2010/334.pdf
> [MACKENZIE] https://eprint.iacr.org/2001/057.pdf
> [LUCENT] http://www.ietf.org/mail-archive/web/tls/current/msg08191.html
> [BONEH] http://cseweb.ucsd.edu/~hovav/dist/sigs.pdf
> [ICART] http://www.iacr.org/archive/crypto2009/56770300/56770300.pdf
> [FIPS186-4] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>


From watsonbladd@gmail.com  Tue Dec 10 17:54:40 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0DA1AE2C1; Tue, 10 Dec 2013 17:54:40 -0800 (PST)
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 MU8hBiri2p3p; Tue, 10 Dec 2013 17:54:38 -0800 (PST)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1E82E1AE0A0; Tue, 10 Dec 2013 17:54:37 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id q58so5795720wes.19 for ; Tue, 10 Dec 2013 17:54:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gucq3GyM0Kfinj5jv6OmNuD2XomJz3+GRxIBYq4MGwk=; b=bUKVq69iikFfJPcIiWNg2wxBdOFGz1zIawm5T3BLM58b0xvDPWZ7fkbjHpqn70d40o m5dpLO6sN3YhwtOLCnFtc80C0zjvU3tnKDV0Il8vf/gUjyfrWODNqgCLZud1ltPM2oDv A02sLEqBcJ9/agGE8vLweRlpSEBiPhrefBOHoavM4WoRVPtHQCz4QRESjFHNUU6dTpxA NlONAyTztqKE/9ueccEVgyO1fx5bf5fAAsFuzlxpnY0i8keRZnHHTclq7DT6hlqX/4SI eQvz1yk2GnH0GydafAejkOqg5xiFQUY1a0SpHE2ZNCefx2coNTIc05swmsPkEkIUvKaY yFPA==
MIME-Version: 1.0
X-Received: by 10.180.24.193 with SMTP id w1mr1765259wif.44.1386726872287; Tue, 10 Dec 2013 17:54:32 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Tue, 10 Dec 2013 17:54:32 -0800 (PST)
In-Reply-To: 
References: 
Date: Tue, 10 Dec 2013 17:54:32 -0800
Message-ID: 
From: Watson Ladd 
To: Trevor Perrin 
Content-Type: text/plain; charset=UTF-8
Cc: cfrg@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Review of Dragonfly PAKE
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 01:54:40 -0000

On Tue, Dec 10, 2013 at 2:30 PM, Trevor Perrin  wrote:
> Dear CFRG (cc: TLS),
>
> Here's a review of the Dragonfly Password-Authenticated Key Exchange (PAKE) from
> draft-irtf-cfrg-dragonfly-02 [CFRGDRAFT].
>
> Overview
> ----
> The Dragonfly PAKE is built on SPEKE with an "obfuscation" applied to
> the exchange of Diffie-Hellman values.  The obfuscation lacks formal
> analysis and serves no obvious purpose, but may be an attempt to avoid
> the SPEKE patent [IPSEC].  Dragonfly has security weaknesses due to
> use of a variable-time algorithm to map a password to an EC point
> [STRUIK], and lack of "augmented" PAKE properties.
>
> Obfuscating the SPEKE DH exchange
> ----
> SPEKE is an old and well-known PAKE [JABLON].  In SPEKE each party
> uses a shared password to derive a Diffie-Hellman generator.  The
> generator is then used for a Diffie-Hellman exchange.
>
> SPEKE is patented until 2017 [SPEKEPATENT].  Alternatives without
> current patents incude [DH-EKE] and [J-PAKE].  Alternatives with
> royalty-free terms include [SRP] and [AUGPAKE].
>
> Dragonfly uses the SPEKE approach but obfuscates the exchange of DH
> values.  In particular, given:
>
>   g : DH generator (calculated by hashing the password)
>   a : Alice's DH private key
>
> In SPEKE, Alice sends g^a.
>
> In Dragonfly, Alice generates a mask m, and sends (a+m, g^-m).  Bob
> uses these values and g to reconstruct g^a.  [ g^a = g^(a+m) * g^-m ]
>
> This obfuscation adds computation and bandwidth costs.  It's not clear
> whether it adds any security benefit.  It's not clear how Dragonfly's
> security relates to SPEKE; whether the SPEKE security proof from
> [MACKENZIE] still applies; or whether another security proof could be
> created.
>
Note Bena: The proof does not address resistance to offline attack,
and uses an assumption that
isn't know to be equivalent to anything.

From ekr@rtfm.com  Tue Dec 10 22:32:50 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F701AE3CC for ; Tue, 10 Dec 2013 22:32:50 -0800 (PST)
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 GZYVwRHXQ4zR for ; Tue, 10 Dec 2013 22:32:47 -0800 (PST)
Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECF81AE3D5 for ; Tue, 10 Dec 2013 22:31:39 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id b13so5882331wgh.6 for ; Tue, 10 Dec 2013 22:31:33 -0800 (PST)
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=LHfsuQNBWIGIo1jomb9yUtFBHkCgSVRZV58qZU2r9go=; b=GzuUvqFrIXB6D/bhP+knTHta8odtOYzlVCyoEgEzTQP0F1rL0ltGn+kMogZPFPpJoH 1nnHisUItP8cp80UYWjbDVEPhqxFdNPl5dpWYyKDaKRzumVWq4GYT/R+SkSUup3gIT2p iRwMFxXNiNV9Z/MZGlfrQAqgu2gUq8M2l78SYYxkLp4pdNAzQXHwLg8lsAP01ayeg7cu c82PzsOptKTRkZzje4vbLMqvW+sZc8StXFEc7EKwHud6FZ7ExfJoXFtuZUKsK+b82gJH lGpRJDgMqsGGbdDdsy4AEUCWZ4dkdLCYPccWQNpKuunwlqRVxvKQlzPI+hSWd0gn8EJA hBjg==
X-Gm-Message-State: ALoCoQnacpofqVQbyWxWFeDAgcwOmOFqQNuQf+2ZI5TNvOXrBmknz++6P6ES+iOX8CE5OcgyjnPE
X-Received: by 10.180.189.6 with SMTP id ge6mr1299274wic.1.1386743493548; Tue, 10 Dec 2013 22:31:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Tue, 10 Dec 2013 22:30:53 -0800 (PST)
X-Originating-IP: [118.163.10.190]
In-Reply-To: 
References: 
From: Eric Rescorla 
Date: Wed, 11 Dec 2013 14:30:53 +0800
Message-ID: 
To: Brian Smith 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" 
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 06:32:50 -0000

Brian,

Thanks for taking the time to send your extensive message about ALPN vs. NPN.

After reviewing your request, the chairs believe that it does not raise any
new substantive issues that were not known to the WG at the time of the
decision to adopt ALPN and the subsequent WGLC. Therefore, we do not
believe it is appropriate to re-open the issue at this time.

Because the document has already passed WGLC, we will be asking the
AD for advancement. You should of course feel free to reraise your objections
during IETF LC.

-Ekr

[For the chairs]



On Mon, Dec 9, 2013 at 11:22 PM, Brian Smith  wrote:
> Hi all,
>
> My name is Brian Smith and I am the lead on Mozilla Corporation's work
> on TLS, PKI, and some related things (though *not* DTLS or other
> WebRTC networking stuff, which EKR does a fine job of leading). I am
> primarily responsible for working to secure Firefox, but most of my
> work also applies to Thunderbird and other software based on our
> "Gecko" engine. Note also that Mozilla has implemented APIs to allow
> certain kinds of HTML5 applications to make TCP connections in a way
> that enables them to implement any TCP protocol (SMTP, IMAP, etc.),
> not just HTTP, SPDY, and WebSockets. Therefore, our interest in
> protocol negotiation goes much further than negotiating just HTTP/1
> vs. HTTP/2, though that is by far the most important use case for us.
>
> For the reasons I note below, I think we should re-evaluate whether we
> still have consensus on moving forward with recommending ALPN as the
> protocol negotiation mechanism to be used in TLS and specifically in
> HTTP/2. I would like the working group to re-consider the option of
> recommending the more secure and more private NPN mechanism instead,
> at least until TLS 1.3 can offer an even better alternative mechanism.
>
> In IETF86, there was some kind of vote in favor of ALPN over NPN. I
> could not attend that IETF for personal reasons, so I don't know the
> nature of the vote or how binding it is and whatnot. Also, I know ALPN
> has gone through WGLC already. I regret that I chose to voice my
> opposition to ALPN only privately to EKR before IETF86 and during
> WGLC. That was definitely a mistake on my part, and I'm truly sorry
> for making it.
>
> Since IETF86, and since WGLC, there have been new developments. I
> tried to go into detail on many of them in the "ALPN concerns" thread,
> but here is a summary:
>
> * During the summer, the Edward Snowden stuff happened, making us
> (more) aware of widespread, worldwide, spying on the users of our
> software. If nothing else, I hope we have learned from Snowden's work
> that we need to be particularly careful to maximize privacy from
> network attackers in the protocols and software we create.
>
> * Stephen Farrell published the first draft of "Pervasive Monitoring
> is an Attack" [0], which states (in part; please read the whole
> thiing):
>
>    The technical plenary of IETF 88 [IETF88Plenary]
>    discussed pervasive monitoring and participants
>    had strong agreement that this was an attack and
>    one that should be mitigated where possible via
>    the design of protocols that make pervasive
>    monitoring significantly more expensive or
>    infeasible.
>    ...
>
>    For the purposes of this BCP "pervasive monitoring"
>    means very widespread privacy-invasive gathering of
>    protocol artefacts including application content,
>    protocol meta-data (such as headers) or keys
>    used to secure protocols.
>    ...
>    This BCP simply records the consensus to design
>    protocols so as to mitigate the attack, where possible.
>
> Note that the protocol/options metadata that would be negotiated in
> ALPN or NPN or whatever is protocol metadata. I think there is no
> disputing that NPN (or a new design that works more like NPN) helps
> make attacks more expensive, even though it may not make any attack
> impossible, and that switching from NPN to ALPN would only help
> facilitate attacks.
>
> * Joseph Salowey wrote the first draft of a proposed new charter for
> the TLS Working Group [1]. That draft says, in part:
>
>     o Develop a mode that encrypts as much of
>       the handshake as is possible to reduce
>       the amount of observable data to both
>       passive and active attackers.
>
> Thus, standardizing unencrypted ALPN now seems likely to be in direct
> contradiction to our future charter.
>
> * During IETF88, EKR published the TLS 1.3 flows draft [2]. This draft
> is extremely helpful for seeing that TLS 1.3 is likely to be quite
> complex, even before we try to encrypt the ALPN and/or SNI extensions
> in the ClientHello. Also, it does not show a viable means of
> encrypting the ALPN extension in a backward-compatible (with
> unencrypted ALPN) way. (A mechanism for encrypting ALPN would have to
> do so without adding any round trips to be viable.) Thus, the idea
> that we can standardize unencrypted ALPN now, and then somehow fix it
> in TLS 1.3, seems extremely unrealistic.
>
> * During IETF87, Microsoft suggested that we need to extend protocol
> negotiation to support the negotiation of options. My understanding is
> that we should expect the HTTP WG to specify some such options in
> HTTP. AFAICT, the need for ALPN or NPN to support an open-ended set of
> negotiated information in addition to the protocol was not considered
> when considering the security of ALPN.
>
> * Mark Nottingham wrote his Opportunistic Encryption for HTTP URIs
> draft [3], which is a specific example of option negotiation described
> in the previous point. Mark also wrote [4] that he is concerned that
> the HTTP 2.0 work may not be able to go forward without a viable means
> of doing opportunistic encryption.
>
> * I described [5] (I recommend reading the whole thread, despite how
> many words there are in it) several technical objections to switching
> to ALPN from NPN on privacy and security groups, and noted that NPN is
> still much more widely deployed and generally meets our goals better.
>
> * I also described [6] how choosing ALPN over NPN would weaken the
> security properties of Mark's Opportunistic Encryption for HTTP draft.
> It is hard to see how it would be reasonable to do opportunistic
> encryption using Mark's proposed mechanism on top of ALPN, considering
> the significant weakness ALPN adds to it, that NPN doesn't.
>
> * In [6], I also showed that it isn't necessarily true that traffic
> analysis can yield information equivalent to ALPN, which was a key
> argument in favor of ALPN. Note that this is just the simplest
> possible example. I think we can be much more successful against
> traffic analysis in general, by adding features to TLS that make
> traffic analysis difficult, such as [7], and I actually don't
> understand why we gives any credence to the "traffic analysis makes
> the argument moot" argument; that seems very defeatist to me. Perfect
> traffic analysis prevention may be impractically expensive, but it is
> far from clear that imperfect traffic analysis is worthless. Tor is a
> pretty good but imperfect mechanism for preventing traffic analysis,
> and it seems to work surprisingly well.
>
> * I described [8] a potential solution for moving the
> application-level protocol negotiation out of the TLS protocol in "TLS
> 1.3" without hurting performance, at least in common cases.
>
> I don't have any political position in the argument of ALPN vs. NPN
> vs. whatever. My concerns are purely technical and purely based on my
> desire to maximize privacy and security for the users of my software
> and even my competitors' software. It is clear to me that ALPN is
> strictly worse than NPN in terms of protecting privacy and security of
> users. (FWIW, it would literally be easier for me to add ALPN support
> to Firefox than it would be for me to have typed up all these messages
> to the working group mailing list.)
>
> We can argue about whether ALPN is "good enough" (and I've argued
> extensively it isn't) but I fail to see why we should settle for
> something worse at all, especially when the choice of NPN better suits
> the motto of the IETF, "rough consensus and running code," as
> demonstrated by the large number of *deployed-in-production* NPN
> implementations. (If you used a web browser today, you probably used
> NPN). Therefore, I strongly encourage people to choose NPN instead of
> ALPN, which is my strong preference for Firefox, Thunderbird, and
> other Mozilla products. And, I would be very happy to do all the
> editing work on the NPN draft to get it into shape for being a
> proposed standard.
>
> Cheers,
> Brian
>
> [0] http://tools.ietf.org/html/draft-farrell-perpass-attack-00
> [1] http://www.ietf.org/mail-archive/web/tls/current/msg10759.html
> [2] http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00
> [3] http://tools.ietf.org/html/draft-nottingham-http2-encryption-01
> [4] http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1453.html
> [5] http://www.ietf.org/mail-archive/web/tls/current/msg10405.html
> [6] http://www.ietf.org/mail-archive/web/tls/current/msg10890.html
> [7] http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00
> [8] http://www.ietf.org/mail-archive/web/tls/current/msg10888.html
>
> [

From dkg@fifthhorseman.net  Wed Dec 11 06:41:56 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23D41ADF87 for ; Wed, 11 Dec 2013 06:41:56 -0800 (PST)
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 IGYvKoGLt0qo for ; Wed, 11 Dec 2013 06:41:54 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C2AD51ADF70 for ; Wed, 11 Dec 2013 06:41:54 -0800 (PST)
Received: from fifthhorseman.net (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id E7F90F985 for ; Wed, 11 Dec 2013 09:41:47 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 46B891FF62; Tue, 10 Dec 2013 15:44:29 -0800 (PST)
From: Daniel Kahn Gillmor 
To: IETF TLS Working Group 
In-Reply-To: <52A7935E.5020906@cs.tcd.ie>
References:  <52A77DB4.7020501@gmx.net> <52A7935E.5020906@cs.tcd.ie>
User-Agent: Notmuch/0.16 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu)
Date: Tue, 10 Dec 2013 18:44:22 -0500
Message-ID: <87ob4o1dbd.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 14:41:57 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue 2013-12-10 17:19:10 -0500, Stephen Farrell wrote:
> FWIW, I agree with you in general, but in this case the privacy
> leak is non-existent if its only HTTP/1.1 vs HTTP/2.0 - since
> the binary encoding and lack of head-of-line blocking in the
> latter will give that game away anyway.

i don't think i understand this argument.  are you saying that traffic
analysis will disclose what protocol is in use in this case?

if so, that's still a win; we've forced a passive attacker to move from
trivial byte-string matching to traffic analysis, which is more complex
and less certain.  And we can further complicate traffic analysis with
other approaches like Pironti's length hiding:

  http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00

And protocol negotiation is not only useful in the HTTP/1.1=E2=86=92HTTP/2.=
0 use
case.

> I'd say focusing on tls1.3 and any privacy gains there is better
> than diverting effort to NPN to be honest.

The concern raised by Brian Smith is that if TLS 1.3 is an upgrade to
TLS 1.2 with cleartext ALPN, based on how we understand negotiated TLS
today, then compliant clients may have a strong incentive to continue to
send cleartext ALPN, so that they can negotiate with servers not yet
capable of TLS 1.3.

If we settle on ALPN now, the information in ALPN seems likely to remain
in the clear for lots of handshakes even after TLS 1.3 is widely
deployed.  If one of the goals of TLS 1.3 is encrypting as much of the
handshake as possible (which i think it should be), then standardizing
ALPN now seems to work against the goals of TLS 1.3 more strongly than
any diversion of effort related to NPN.

        --dkg

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQJ8BAEBCgBmBQJSp6dXXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc46oQAMnag8D8JSkoclrJ/jM3IhmM
h07eipsne2xwulqXbPa1/c9d75aFgIR4eqSZU29VREBNXzozSo1VtCgD9didPUvQ
jyNwA8NNqz5vDJCuVsRzkIvR1Ha05wguyD8S02aVYA63+tArmtkYQd/GCX8qwWGr
+dYweboenPidh9wIYu2YsZshh8LDRJPNKsLNWQws6zLoxtR1eCAzdhR/igOpAdkB
MhyJiPIT8IsBkFpD71a8gQ1UhP+fTanb9yeanFHy8+RuWY4+iaQwSzBBssdrO7Ze
5UUfldJ2sm1PBL9SZRsIvAAbOZm1zDEygSaYWYamk5qRlSLwLwEXbr2j6GK8q9Jx
34YaJkU7hpvXDX4t1rqPPNPSwEj8xmF1iSPIvC8W7tDj1NBM6HguZnSciBKgkBgW
P5fRPojNohs+3wSl3nXdz4Bi3zcARBtFhwrxtLtMi9aDtDRwXwr2iuMPAfIaBc5I
GlvKZQUSaZWqT6ZY+ELgQ3Pc8Y4DPfrMnFTbueMvQQBoHB2WsgB6Byi8wgSfaXQp
Cpe46G4BNC1bo9lYnGb5AKtexZwdeA3AWGGxUhepHg8GcFhh8akxi8G1i/Qx/BLi
zZGfHX5c/y2rc+BYe+gZeYNikSqifGsPtcOFSZo8wOLqFTueHc2VO0GVHWN28uXI
wgKymHnfCUna6153TDZG
=2Di+
-----END PGP SIGNATURE-----
--=-=-=--

From stephen.farrell@cs.tcd.ie  Wed Dec 11 07:04:43 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6943D1ADF82 for ; Wed, 11 Dec 2013 07:04:43 -0800 (PST)
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, RP_MATCHES_RCVD=-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 dzIlELP8PZff for ; Wed, 11 Dec 2013 07:04:40 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E60E21ADED6 for ; Wed, 11 Dec 2013 07:04:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D13DFBE63; Wed, 11 Dec 2013 15:04:33 +0000 (GMT)
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 878eCD287L5W; Wed, 11 Dec 2013 15:04:33 +0000 (GMT)
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 F21A1BE88; Wed, 11 Dec 2013 15:04:32 +0000 (GMT)
Message-ID: <52A87F00.7000304@cs.tcd.ie>
Date: Wed, 11 Dec 2013 15:04:32 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Daniel Kahn Gillmor ,  IETF TLS Working Group 
References:  <52A77DB4.7020501@gmx.net> <52A7935E.5020906@cs.tcd.ie> <87ob4o1dbd.fsf@alice.fifthhorseman.net>
In-Reply-To: <87ob4o1dbd.fsf@alice.fifthhorseman.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 15:04:43 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 12/10/2013 11:44 PM, Daniel Kahn Gillmor wrote:
> On Tue 2013-12-10 17:19:10 -0500, Stephen Farrell wrote:
>> FWIW, I agree with you in general, but in this case the privacy 
>> leak is non-existent if its only HTTP/1.1 vs HTTP/2.0 - since the
>> binary encoding and lack of head-of-line blocking in the latter
>> will give that game away anyway.
> 
> i don't think i understand this argument.  are you saying that
> traffic analysis will disclose what protocol is in use in this
> case?

I believe so, esp since there's just http/1.1 and http/2.0 in
question (well, maybe spdy too for some time). If hiding that
somewhat is the claimed benefit and if that diverted scarce
WG resources away from tls1.3 then I figure doing the work
in tls1.3 is better.

> if so, that's still a win; we've forced a passive attacker to move
> from trivial byte-string matching to traffic analysis, which is
> more complex and less certain.

If we're only dealing with the above protocols, then I don't
think it'd be at all hard to distinguish 'em.

> And we can further complicate traffic analysis with other
> approaches like Pironti's length hiding:
> 
> http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00

I really like the idea of meeting that requirement. But again
it seems to me like it'd be better baked into tls1.3 and not
done as an extension to tls1.2 or earlier. My reasoning there
assumes that we figure tls1.3 will be widely deployed more
quickly than previous updates due to the collective win of
running http/2.0 over tls1.3. Doing a lot of things in both
tls1.3 and as extensions to earlier versions also seems less
likely to work out, given that we all have limited cycles.

But yes, that's prediction with which one could disagree.

> And protocol negotiation is not only useful in the
> HTTP/1.1?HTTP/2.0 use case.
> 
>> I'd say focusing on tls1.3 and any privacy gains there is better 
>> than diverting effort to NPN to be honest.
> 
> The concern raised by Brian Smith is that if TLS 1.3 is an upgrade
> to TLS 1.2 with cleartext ALPN, based on how we understand
> negotiated TLS today, then compliant clients may have a strong
> incentive to continue to send cleartext ALPN, so that they can
> negotiate with servers not yet capable of TLS 1.3.

Yep, that is a good question to consider. I don't think I've seen
it addressed either, but maybe I missed that.

> If we settle on ALPN now, the information in ALPN seems likely to
> remain in the clear for lots of handshakes even after TLS 1.3 is
> widely deployed.  If one of the goals of TLS 1.3 is encrypting as
> much of the handshake as possible (which i think it should be),
> then standardizing ALPN now seems to work against the goals of TLS
> 1.3 more strongly than any diversion of effort related to NPN.

Depends on what ALPN values would be present in a case where tls1.3
and http/2.0 are supported. I don't know what'd be likely there.

S.

> 
> --dkg
> 
> 
> 
> _______________________________________________ TLS mailing list 
> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJSqH77AAoJEC88hzaAX42illgIAJltllnhLB3xGbHF/l6ul3nU
Mzd8kvF9W27zRoGg0L1noxfQEawGyOjfRFxGXVO3BYHvXMSIfpAOC5vKWPnY/Hlc
T2ZkklFk9bTq/b7PIJlmSlPTPqBBUCHlZkxxzlO5GeGwjXahOS7M+kc20/ufMHKG
UGScMtzV5cx3fDQBAPBXjU5w9WHNz0LnLrti9q682g11a4nyRNKvPuaa8ujr4Ona
dDtGKIk6ITr6DthO5IrhTEdRpR9/AgpR8WrXslMTKldELw6Inf4dBKOOkOJtnptA
OTbtozBtlyvMQCHSxoVEb0FS5AgXFvTVL9t3SY/1BcYmzvbjvYl/XP1kNI8VTS4=
=JATC
-----END PGP SIGNATURE-----

From ynir@checkpoint.com  Wed Dec 11 07:16:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7281AD75F for ; Wed, 11 Dec 2013 07:16:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level: 
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 5PjrBeHYXiQ6 for ; Wed, 11 Dec 2013 07:16:40 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1B31AC421 for ; Wed, 11 Dec 2013 07:16:39 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rBBFGU9D012429; Wed, 11 Dec 2013 17:16:30 +0200
X-CheckPoint: {52A87E43-3-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.146]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 17:16:30 +0200
From: Yoav Nir 
To: Daniel Kahn Gillmor , IETF TLS Working Group 
Thread-Topic: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
Thread-Index: AQHO9PKwvFEdHESyEEm0ZUd+bMkQKppNxnIAgAAZ0wCAABfOAIABARgAgAAiFBA=
Date: Wed, 11 Dec 2013 15:16:29 +0000
Message-ID: <4613980CFC78314ABFD7F85CC302772121B21CE3@IL-EX10.ad.checkpoint.com>
References:  <52A77DB4.7020501@gmx.net> <52A7935E.5020906@cs.tcd.ie> <87ob4o1dbd.fsf@alice.fifthhorseman.net> <52A87F00.7000304@cs.tcd.ie>
In-Reply-To: <52A87F00.7000304@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [91.90.139.27]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 15:16:41 -0000

I think it's possible to get all the extension hiding we want in TLS 1.3, e=
ven while keeping BC with TLS 1.0 servers:

1. Client sends ClientHello without the problem extensions (ALPN, SNI). The=
 record version is 3.1 (TLS 1.0), while the supported version is 3.4 (TLS 1=
.3).=20

2a. The server replies with TLS 1.3, and everything works as planned. The e=
nd.

2b. The server replies with TLS 1.0, and some certificate. The certificate =
may or may not fit the site. Makes no difference for now.
3b. The client completes the exchange, and immediately begins a renegotiati=
on
4b. In this renegotiation, the versions offered are just TLS 1.0 to TLS 1.2=
, and all extensions are present (though encrypted).
5b. The renegotiation completes at TLS 1.0 with all extensions.

This solves the issue of hiding extension. If TLS 1.3 is not supported by t=
he server, it means an extra handshake with all associated costs. It may be=
 possible, if the server presented the correct certificate to have session =
resumption with the renegotiation, although that is usually not recommended=
.

Yoav

From skyper@thc.org  Wed Dec 11 08:03:23 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522101AE01E for ; Wed, 11 Dec 2013 08:03:23 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 TXo6DevaApM8 for ; Wed, 11 Dec 2013 08:03:21 -0800 (PST)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C9C0D1AE028 for ; Wed, 11 Dec 2013 08:03:20 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id as1so11319154iec.13 for ; Wed, 11 Dec 2013 08:03:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uwknjnpzePRsg0+e5jpYOeljmFBTkpKeTwwr5TaZrfA=; b=A9rJbRdaKvrdulBqXOr1m8vHcifWniF49Ugjxjl3mJW7q2DA2eLhY1F8d/earrk1dF 5dup++jOJKtHcG1wADaEbZ3tnCEjHe40LjssSCdSqhi/rtxTpZtOh02jbVtI8YNFVEoq BqT4MWvPpWi0ysvLcS0dKYMCKs7K8gu/cSzC0=
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=uwknjnpzePRsg0+e5jpYOeljmFBTkpKeTwwr5TaZrfA=; b=aqbeMGERDBsgK3sKGnYwiNpLzMrTG8tPSq/fh9fX+Qt6fZWvNl2km2V72XOiZWst68 xGF3G6zIY28fr9KwBGcr5p2KJSm7VIhfIHkHb5RMwIgZR+Hy+2IFxXG8zskBD//+vb8i dBFwzmugmF/AOzrru5N+7iAP9ZW1su+f/PgBtQqEXduCIq+Y4w0ZbAtWMn5Xf7tKGRWE vv5xt52chKJhF7egyU8b46UyTC+PvpJ4Kc68Bc/Ipv0MI4wONyD7I+diHo1n2TyQuXJ3 RiR3DLkUHBxb03zXSkgL0lt6VEiEhZm9UTQFh0NL7+CM0mmFi9pxUhISroS/zBh4E4fx rlCg==
X-Gm-Message-State: ALoCoQm+Oyo8Q3zlj18yV6aMWwET403DDqEnpwYyjDuVR8ae3EBRjOhK4qYYeOCFMk2wGTVKXFXO
MIME-Version: 1.0
X-Received: by 10.43.0.202 with SMTP id nn10mr1521402icb.54.1386777794860; Wed, 11 Dec 2013 08:03:14 -0800 (PST)
Received: by 10.64.9.41 with HTTP; Wed, 11 Dec 2013 08:03:14 -0800 (PST)
X-Originating-IP: [81.156.248.122]
In-Reply-To: <7a5a264b029777f3c0b2d2f97a362463.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com>  <7a5a264b029777f3c0b2d2f97a362463.squirrel@www.trepanning.net>
Date: Wed, 11 Dec 2013 16:03:14 +0000
Message-ID: 
From: Ralf Skyper Kaiser 
To: Dan Harkins 
Content-Type: multipart/alternative; boundary=bcaec5101cbbd86ebf04ed445dbb
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 16:03:23 -0000

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

Hi,

I'm concerned that it will happen in practice: Same password for all users
to authenticate the server.

I feel that the risk should be mentioned under 'Security Considerations'.

"It should be noted that any user with the knowledge of the password can
impersonate the server and perform
a Man-in-the-middle attack against any other user who is using the same
password".

(Maybe some native english speaker can make this sound like Prince Charles
would say it.)

Comments welcome,

regards,

ralf


On Tue, Dec 10, 2013 at 10:06 PM, Dan Harkins  wrote:

>
>   Hi Ralf,
>
> On Tue, December 10, 2013 8:45 am, Ralf Skyper Kaiser wrote:
> > Hi,
> >
> > I only joined the conversation recently. Had a quick read of
> > http://tools.ietf.org/html/draft-ietf-tls-pwd-02 and have a question:
> >
> > In a scenario where multiple users use the same password (group
> password):
> >
> > What prevents a user (who knows the password) to impersonating the server
> > and mount a MITM between another user and the real server?
>
>   Nothing prevents that. This protocol is not designed to support group
> passwords. The password credential is assumed to be shared between
> the client and the server only.
>
>   regards,
>
>   Dan.
>
>
>

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


Hi,

I'm concerned tha=
t it will happen in practice: Same password for all users to authenticate t=
he server.

I feel that the risk should be mentioned under '=
;Security Considerations'.


"It should be noted that any user with the knowledge of the =
password can impersonate the server and perform
a Man-in-the-middle atta=
ck against any other user who is using the same password".


(Maybe some native english speaker can make this sound like Prince Charles =
would say it.)

Comments welcome,

regards,

ralf


On Tu=
e, Dec 10, 2013 at 10:06 PM, Dan Harkins <dharkins@lounge.org> wrote:




=A0 Hi Ralf,




On Tue, December 10, 2013 8:45 am, Ralf Skyper Kaiser wrote:

> Hi,

>

> I only joined the conversation recently. Had a quick read of

> http://tools.ietf.org/html/draft-ietf-tls-pwd-02 and have a qu=
estion:

>

> In a scenario where multiple users use the same password (group passwo=
rd):

>

> What prevents a user (who knows the password) to impersonating the ser=
ver

> and mount a MITM between another user and the real server?




=A0 Nothing prevents that. This protocol is not designed to support g=
roup

passwords. The password credential is assumed to be shared between

the client and the server only.



=A0 regards,



=A0 Dan.









--bcaec5101cbbd86ebf04ed445dbb--

From dharkins@lounge.org  Wed Dec 11 08:35:04 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335671ADF52 for ; Wed, 11 Dec 2013 08:35:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 RHdd8TcGXb-h for ; Wed, 11 Dec 2013 08:34:46 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8191ADEA7 for ; Wed, 11 Dec 2013 08:34:46 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id BDE8A10224008; Wed, 11 Dec 2013 08:34:40 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 11 Dec 2013 08:34:40 -0800 (PST)
Message-ID: <6a1396f13bf6bd2e78957a8f5f7e3e9e.squirrel@www.trepanning.net>
In-Reply-To: 
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com>  <7a5a264b029777f3c0b2d2f97a362463.squirrel@www.trepanning.net> 
Date: Wed, 11 Dec 2013 08:34:40 -0800 (PST)
From: "Dan Harkins" 
To: "Ralf Skyper Kaiser" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 16:35:04 -0000

  Hi Ralf,

On Wed, December 11, 2013 8:03 am, Ralf Skyper Kaiser wrote:
> Hi,
>
> I'm concerned that it will happen in practice: Same password for all users
> to authenticate the server.
>
> I feel that the risk should be mentioned under 'Security Considerations'.
>
> "It should be noted that any user with the knowledge of the password can
> impersonate the server and perform
> a Man-in-the-middle attack against any other user who is using the same
> password".
>
> (Maybe some native english speaker can make this sound like Prince Charles
> would say it.)
>
> Comments welcome,

  I will add such a note to the Security Considerations, although I can't
guarantee it will sound like Prince Charles :-)

  thanks for your suggestion,

  Dan.

> regards,
>
> ralf
>
>
> On Tue, Dec 10, 2013 at 10:06 PM, Dan Harkins  wrote:
>
>>
>>   Hi Ralf,
>>
>> On Tue, December 10, 2013 8:45 am, Ralf Skyper Kaiser wrote:
>> > Hi,
>> >
>> > I only joined the conversation recently. Had a quick read of
>> > http://tools.ietf.org/html/draft-ietf-tls-pwd-02 and have a question:
>> >
>> > In a scenario where multiple users use the same password (group
>> password):
>> >
>> > What prevents a user (who knows the password) to impersonating the
>> server
>> > and mount a MITM between another user and the real server?
>>
>>   Nothing prevents that. This protocol is not designed to support group
>> passwords. The password credential is assumed to be shared between
>> the client and the server only.
>>
>>   regards,
>>
>>   Dan.
>>
>>
>>
>


From frantz@pwpconsult.com  Wed Dec 11 11:14:30 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82271AE133 for ; Wed, 11 Dec 2013 11:14:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 MMKmThZyvy4X for ; Wed, 11 Dec 2013 11:14:29 -0800 (PST)
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 093441AE12C for ; Wed, 11 Dec 2013 11:14:28 -0800 (PST)
Received: from [173.75.83.15] (helo=Williams-MacBook-Pro.local) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VqpEl-00023k-5N for tls@ietf.org; Wed, 11 Dec 2013 14:14:23 -0500
Date: Wed, 11 Dec 2013 11:14:17 -0800
From: Bill Frantz 
To: tls@ietf.org
X-Priority: 3
In-Reply-To: <87ob4o1dbd.fsf@alice.fifthhorseman.net>
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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79864039514122a9b1a8db843d84d608b7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 173.75.83.15
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 19:14:31 -0000

 From the desires people are putting into tls 1.3 perhaps we are=20
actually talking about tls 2.0.

We should not insist that a client using the new protocol be=20
able to connect of a tls 1.2 server (or below) as a result of=20
tls level negotiation. The fallback mechanisms in most browsers=20
can cover that need. The extra design freedom will allow us to=20
easily encrypt data that was previously sent in the clear=20
without worrying about backward compatibility.

We may find the resulting simplicity a clear win.

I would be delighted to be wrong and see a simple tls 1.3 negotiation.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345=20
Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos,=20
CA 95032


From trevp@trevp.net  Wed Dec 11 11:50:56 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DD41AE1FC for ; Wed, 11 Dec 2013 11:50:56 -0800 (PST)
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=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 z_MSnPNEB_IF for ; Wed, 11 Dec 2013 11:50:54 -0800 (PST)
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id CF36E1AE1EB for ; Wed, 11 Dec 2013 11:50:53 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id a1so6990570wgh.29 for ; Wed, 11 Dec 2013 11:50:47 -0800 (PST)
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=fZdm//FWEaxLbtx6WBewc/IuSnsRCm7tj8gGw/1fc1g=; b=GoJxA6wnMF+a1MRiiwAckyysmIfSsxlkywwh0x19Ft9z31XhU3OHvdk04vKyhZU/7t MWvBH1iQPczaZlFtYzf/FbsL5jtRhD3UeruydQFAfpucCy4GjZ+ZC26/8TMNh7yBD08t XaXxn+Uds5B+WKpPVdlO0yfTciKZG5gpxwHQxOkSmEG0WlLOfDeCY+/bsGsu9Onwbonl cflkeCDRwdIFE0us5DkhuRod3pFgvWfcwIVehFybIvMFk8IXcfXrK4Dal4OPIYuHVO0G 5JR1Rjc89kia1D7FDoHMKzukxQLHgkw23IKPkh5/ijHwKUfklz3EJuYVS1tmiweTn+UL qD1g==
X-Gm-Message-State: ALoCoQn/fatref2RtTDvVhXZl4uaUHudrSPdkvxhRY03snZabfgboKNgFjWxMNfVX4nZ01O0ncBB
MIME-Version: 1.0
X-Received: by 10.180.9.74 with SMTP id x10mr25870723wia.56.1386791447692; Wed, 11 Dec 2013 11:50:47 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Wed, 11 Dec 2013 11:50:47 -0800 (PST)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <081a8a74fc0084dcff176b07a7502c93.squirrel@www.trepanning.net>
References:  <081a8a74fc0084dcff176b07a7502c93.squirrel@www.trepanning.net>
Date: Wed, 11 Dec 2013 11:50:47 -0800
Message-ID: 
From: Trevor Perrin 
To: Dan Harkins 
Content-Type: text/plain; charset=ISO-8859-1
Cc: cfrg@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Review of Dragonfly PAKE
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 19:50:56 -0000

On Tue, Dec 10, 2013 at 5:35 PM, Dan Harkins  wrote:
>
>   Hi Trevor,
>
> On Tue, December 10, 2013 2:30 pm, Trevor Perrin wrote:
>> Dear CFRG (cc: TLS),
>>
>> Here's a review of the Dragonfly Password-Authenticated Key Exchange
>> (PAKE) from
>> draft-irtf-cfrg-dragonfly-02 [CFRGDRAFT].
>>
>> Overview
>> ----
>> The Dragonfly PAKE is built on SPEKE with an "obfuscation" applied to
>> the exchange of Diffie-Hellman values.
>
>   I disagree with this over-simplification.
>
>>                                                             The
> obfuscation
> lacks formal
>> analysis and serves no obvious purpose, but may be an attempt to avoid
>> the SPEKE patent [IPSEC].  Dragonfly has security weaknesses due to
>> use of a variable-time algorithm to map a password to an EC point
>> [STRUIK], and lack of "augmented" PAKE properties.
>
>   What is a "weakness" from the point of view of an augmented PAKE
> scheme is a benefit from the point of view of a balanced PAKE scheme.
> Augmented PAKE schemes bind the password to a single domain
> parameter set while balanced PAKE schemes allow for the domain
> parameter set to be negotiated. This allows, for example, a domain
> parameter set to be agreed upon that provides commensurate
> security to the rest of the cipher suite with which it can be used.
>
>   It makes little sense to negotiate a 256-bit or even a 128-bit
> cipher or a hash algorithm with a 256-bit or 512-bit digest size
> when the domain parameter set is fixed to a 1024-bit FFC group.
> What makes sense is to allow for negotiation of a 4096-bit FFC
> group or a 256-bit ECC group along with your AES-GCM-128
> with key derivation using HMAC-256.

It makes little sense to use a 1024-bit FFC group in any circumstances
because (pardon me, Kevin) - fuck the NSA.

Having server-side password-data be flexible to different DH groups
seems of little value.  For a typical password auth performed over an
existing encrypted session, the PAKE DH group is already decoupled
from the session's DH group.

I prefer the security benefit of an augmented PAKE.


>   A balanced PAKE scheme in addition to the existing augmented
> PAKE scheme offers choice. You want to restrict and prohibit
> choice.

I think augmented PAKEs are preferable.  But if you really want a
balanced PAKE, there are many better than Dragonfly (e.g. DH-EKE,
SPAKE2, J-PAKE).


>> Obfuscating the SPEKE DH exchange
>> ----
>> SPEKE is an old and well-known PAKE [JABLON].  In SPEKE each party
>> uses a shared password to derive a Diffie-Hellman generator.  The
>> generator is then used for a Diffie-Hellman exchange.
>>
>> SPEKE is patented until 2017 [SPEKEPATENT].  Alternatives without
>> current patents incude [DH-EKE] and [J-PAKE].  Alternatives with
>> royalty-free terms include [SRP] and [AUGPAKE].
>
>   AugPAKE has particularly nasty terms as the license explicitly
> states that the "royalty-free" license does not cover all the claims
> in the patent yet it does not spell out exactly which ones are or
> are not covered. If your legal council advises you accept such a
> license I'd advise you get new legal council.

The AugPAKE IPR declaration is not a license, it's a declaration that
the AugPAKE patent holders will make a royalty-free license available
*if* the IETF adopts AugPAKE on the standard track.

I hope the AugPAKE inventors have seen enough IETF incompetence to
rethink tying AugPAKE's future to the IETF.  I would certainly prefer
a royalty-free license without such restrictions.

But I see no basis for questioning the honesty of the AugPAKE IPR declaration.


>> Dragonfly uses the SPEKE approach but obfuscates the exchange of DH
>> values.  In particular, given:
>>
>>   g : DH generator (calculated by hashing the password)
>>   a : Alice's DH private key
>>
>> In SPEKE, Alice sends g^a.
>>
>> In Dragonfly, Alice generates a mask m, and sends (a+m, g^-m).  Bob
>> uses these values and g to reconstruct g^a.  [ g^a = g^(a+m) * g^-m ]
>>
>> This obfuscation adds computation and bandwidth costs.  It's not clear
>> whether it adds any security benefit.  It's not clear how Dragonfly's
>> security relates to SPEKE; whether the SPEKE security proof from
>> [MACKENZIE] still applies; or whether another security proof could be
>> created.
>
>   Apparently much is not clear to you. I will tell you that I do not believe
> that sending (a+m, g^-m) with a password-derived g has any security
> benefits over sending g^a with a password-derived g. Does that clear
> anything up?

Yes.  You added a gimmick to SPEKE, hoping to avoid its IPR.


>> The Dragonfly author argues that the SPEKE patent only covers use of a
>> "password-based parameter" with a "known technique of unauthenticated
>> key distribution" [IPSEC], and thus does not apply to Dragonfly.
>>
>> It's not obvious that this is true.
>
>   That is truly a content-free statement, especially given the subject matter
> (IPR). The reference you give goes to some lengths to explain the rationale
> behind that statement. Sadly your response does not address any points
> made in that reference, and, in fact, contributes nothing.

That thread develops your theory about how the SPEKE patent only
applies to a "known technique of unauthenticated key distribution",
and how your gimmick transforms DH into something unknown, thus
avoiding it.

I'm not qualified to assess this argument, but it seems dubious.  The
primary innovation in SPEKE is mapping a password to a DH base point,
which is used in Dragonfly.  Adding innovations onto an existing
patented work does not free you from the earlier patent.

Perhaps I'm wrong.  But the patent situation in the rest of the PAKE
world seems much clearer.  The last Lucent EKE patent expired a few
months ago.  As that was from the inventors of the PAKE concept, it
cast a bit of a pall over the whole area.  But now that's gone.

I'm particularly leery of the SPEKE patents, as the patent holder used
to aggressively pursue licensing.

So while I support steering clear of difficult IPR, I think there are
easier ways of doing it.


> Maybe this too is
> not clear to you so let me give a brief attempt to make it more obvious:
>
>   - if you replace the password-derived generator from SPEKE with the
>      generator from the domain parameter set what do you have? You have
>      the Diffie-Hellman key exchange, a "known technique of unauthenticated
>      key distribution."
>
>   - if you replace the password-derived generator from dragonfly with
>      the generator from the domain parameter set what do you have? Well,
>      whatever it is it is certainly not a "known technique of unauthenticated
>      key distribution." I had never seen this technique of unauthenticated
>      key distribution. If you have, please provide me with a reference from
>      before 2007 or so.

To me, it looks like Diffie-Hellman with a silly gimmick.


>> Sidechannel attack on mapping password to EC point
>> ----
>> Mapping a password onto a Diffie-Hellman generator is easy for
>> Diffie-Hellman with safe primes, which are typically used with SPEKE.
>> For ECDH, the naive "try-and-increment" algorithm for mapping to a
>> point leaks timing information about its input ([BONEH], [ICART]).
>>
>> Nonetheless, this algorithm might be acceptable provided its input is
>> fixed for a given password.  Unfortunately, Dragonfly recommends
>> mixing nonces with the password prior to "hunting-and-pecking".  This
>> enables a timing attack:
>
>   This has been discussed on both the TLS and CFRG lists already.
>
>>  * The attacker initiates many protocol runs, recording the time taken
>> by the server to produce each Commit message.  (Alternatively, the
>> attacker passively observes many protocol runs.)
>>
>>  * Afterwards, for each offline password guess, the attacker predicts
>> how long the "hunting-and-pecking" algorithm would have taken for each
>> run.
>
>   Except that the amount of time is hidden by a constant number of
> loops through the hunting-and-pecking loop. Given that randomness
> replaces the base once PE is obtained, it makes it all the more difficult
> for the attacker to use any recorded time from a run of the protocol
> or to make any prediction on the amount of time it would take.

Except that sidechannel attacks use statistics, so injecting noise
just increases the number of measurements required.

Modern crypto practice is to prefer constant-time algorithms when
remote timing attacks are possible, as in this case.


>> This attack is easily avoided by omitting nonces from the input to the
>> "hunting-and-pecking" loop.  However, variants of the attack may be
>> possible (e.g. using salt to attack the client).  Difficulties of this
>> sort are why PAKE schemes often avoid the EC setting.
>
>   The current "hunting-and-pecking" text in draft-ietf-tls-pwd is
> the result of a discussion with numerous people on a long thread on
> the TLS list from an earlier version of the draft. Given that you have
> obviously spent a considerable amount of time scouring through
> numerous email lists that should be known to you.

Yes, I see people like Rene Struik recommended not mixing the nonces
in multiple times [1,2].

Even Kevin Igoe - a fount of bad advice, generally - mentioned this
once, before agreeing that just looping a shit-ton of times was an
"elegant change" [3,4].


> I'm not really sure
> why you have waited until now to comment on it but I'm glad you have,
> so let me ask:
>
>   - what change would you like to see in the text and why? And,
>
>   - if I accommodated your change would you support this draft?

I won't support this draft even with the gratuitous sidechannel problem fixed.

I think it's a bad PAKE and there are many better ones (DH-EKE,
SPAKE2, J-PAKE, SRP, AugPAKE, and probably others).


>   I'm also not sure why you have become a cheerleader for AugPAKE,
> especially given your previous statements about: 1) how nobody
> wants any PAKE solution in TLS; 2) that we have SRP and that can
> address the few people (in your mind) who want it; and, 3) how you
> would be against any additional PAKE scheme in TLS. It's especially
> bizarre given that AugPAKE offers nothing on top of what SRP already
> offers.

1 and 2 are true.  I don't understand why CFRG is reviewing this, or
why the TLS WG is considering TLS-PWD.

According to chair Kevin Igoe, Dragonfly "fills a real need" [5].
Perhaps he can explain.

(I'm not a cheerleader for AugPAKE.  It's one of many protocols that
are better than Dragonfly).


>> Conclusions
>> ------------
>> The Dragonfly approach seems inferior to existing PAKE schemes due to:
>>  * Lack of formal security proofs or extensive cryptanalysis
>>
>>  * An unclear IPR situation compared to alternatives
>
>   It is extremely clear; it's not patented. Would you would like me to give
> you a "royalty-free" license to use an unpatented protocol? Would you like
> it to include all of the claims in a patent that does not exist or would you
> be OK with it if it excluded some claims in a patent that does not exist?

I'd prefer to use PAKEs which steer clear of the SPEKE approach entirely.


>>  * High computation cost due to "hunting-and-pecking" and "DH obfuscation"
>>  * Side-channel risks due to "hunting-and-pecking"
>>  * Non-augmented properties
>
>   Aside from the last one, which is your personal preference which has
> really no bearing on the personal preferences of anyone else, what would
> you like to see change in the draft?

I don't support this draft.  I think it's a bad PAKE and there are better ones.


Trevor


[1] http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html
[2] http://www.ietf.org/mail-archive/web/cfrg/current/msg03527.html
[3] http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html
[4] http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html
[5] http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html

From dkg@fifthhorseman.net  Wed Dec 11 13:50:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2CA1AE148 for ; Wed, 11 Dec 2013 13:50:41 -0800 (PST)
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 w2NWA41xQp7k for ; Wed, 11 Dec 2013 13:50:39 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8DF1AE11B for ; Wed, 11 Dec 2013 13:50:39 -0800 (PST)
Received: from [192.168.23.229] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 73697F984; Wed, 11 Dec 2013 16:50:32 -0500 (EST)
Message-ID: <52A8DE25.4070905@fifthhorseman.net>
Date: Wed, 11 Dec 2013 16:50:29 -0500
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
To: Yoav Nir , IETF TLS Working Group 
References:  <52A77DB4.7020501@gmx.net> <52A7935E.5020906@cs.tcd.ie> <87ob4o1dbd.fsf@alice.fifthhorseman.net> <52A87F00.7000304@cs.tcd.ie> <4613980CFC78314ABFD7F85CC302772121B21CE3@IL-EX10.ad.checkpoint.com>
In-Reply-To: <4613980CFC78314ABFD7F85CC302772121B21CE3@IL-EX10.ad.checkpoint.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0T79H357P7C6LS2v0lgjIj23hmdM9mWd8"
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 21:50:41 -0000

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

On 12/11/2013 10:16 AM, Yoav Nir wrote:
> I think it's possible to get all the extension hiding we want in TLS 1.=
3, even while keeping BC with TLS 1.0 servers:
>=20
> 1. Client sends ClientHello without the problem extensions (ALPN, SNI).=
 The record version is 3.1 (TLS 1.0), while the supported version is 3.4 =
(TLS 1.3).=20
>=20
> 2a. The server replies with TLS 1.3, and everything works as planned. T=
he end.
>=20
> 2b. The server replies with TLS 1.0, and some certificate. The certific=
ate may or may not fit the site. Makes no difference for now.
> 3b. The client completes the exchange, and immediately begins a renegot=
iation
> 4b. In this renegotiation, the versions offered are just TLS 1.0 to TLS=
 1.2, and all extensions are present (though encrypted).
> 5b. The renegotiation completes at TLS 1.0 with all extensions.

This approach should work to hide all extensions in current versions of
TLS as well, right?  But no one does it, as far as i know.

Do you know of any TLS client library which does this, or provides an
option to do it without a bunch of manual intervention in the workflow
of the TLS stack by the library user?  Do you think certain tools or
users should be doing this now?

Are there any extensions which require that their content must be
identical across session resumption or across a re-handshake?

If so, it doesn't seem like those extensions could be used in this
re-handshake approach.


	--dkg



--0T79H357P7C6LS2v0lgjIj23hmdM9mWd8
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.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQJ8BAEBCgBmBQJSqN4lXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc6FMQAMw39VDSAZn+lz6JwxhNG296
TjcEszLAL9zZ/l5j6e+W3kESxKkFk61sXJYdoYVdS0Lask2JoLuxX6Ev4uStpE+b
NnA/uB679NO405WNArm1cUwG6yC5eskv9UGM3ha5ufF+sg1wj3DbXyayaQ8uQCul
/fZeeu+xzUgr602IM87YyTnE26SWuqwKt9sbOMK2zX/7IbaSQTGoWMuQlEg5g1yi
qfphSFgr1unAul3xgRKM0s10xfsRqppwgNdyB7PJUtt/4Zz5v78XYnw9hUWfs7Mx
G+AvVCGtxpzGNXaDn2CPVTVvrsT9yOXQthUD9V7dxqm5Iwduu09niqWwqPd/s0h0
g95LH/vxEnXZWdQyTLKbwogPFZoDpTHAdt44ek7BTChvveTsuDGEY9Wm1WYBUx51
kS8j786EqQFWKTC0GrfWFgamdRU/vuasXGmRLTYBhpvWQvaWfZmlKIXxf4kB6W2J
fiGCLnqDTO0iSQErNNJAmXNwn8Xo/4S5eLx1xgP6GmDQerUeHwiMTwC0qVzv/A/r
S3qf98DIIgXeaUcpxmfn08XapCc+lAR1W+3HSk7OBro1/eWDTrapu92v9/fVLsxi
uRcl/SY+RogddmzZPWhl6SgFeP6yt6HVI6SRWltB2wKt1adbk6TT9p3F8O8qQHmA
psZTBtE9NsSTiT/GZnhS
=EfM5
-----END PGP SIGNATURE-----

--0T79H357P7C6LS2v0lgjIj23hmdM9mWd8--

From dharkins@lounge.org  Wed Dec 11 14:07:16 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3FB1ADF90; Wed, 11 Dec 2013 14:07:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 TNCWBHV0N_4d; Wed, 11 Dec 2013 14:07:14 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A5B4B1ADF58; Wed, 11 Dec 2013 14:07:14 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0109F10224008; Wed, 11 Dec 2013 14:07:08 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 11 Dec 2013 14:07:09 -0800 (PST)
Message-ID: <59b169e8fb0405cfef0cb4a397668d7d.squirrel@www.trepanning.net>
In-Reply-To: 
References:  <081a8a74fc0084dcff176b07a7502c93.squirrel@www.trepanning.net> 
Date: Wed, 11 Dec 2013 14:07:09 -0800 (PST)
From: "Dan Harkins" 
To: "Trevor Perrin" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: cfrg@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Review of Dragonfly PAKE
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 22:07:16 -0000

On Wed, December 11, 2013 11:50 am, Trevor Perrin wrote:
> On Tue, Dec 10, 2013 at 5:35 PM, Dan Harkins  wrote:
[snip]
>>   It makes little sense to negotiate a 256-bit or even a 128-bit
>> cipher or a hash algorithm with a 256-bit or 512-bit digest size
>> when the domain parameter set is fixed to a 1024-bit FFC group.
>> What makes sense is to allow for negotiation of a 4096-bit FFC
>> group or a 256-bit ECC group along with your AES-GCM-128
>> with key derivation using HMAC-256.
>
> It makes little sense to use a 1024-bit FFC group in any circumstances
> because (pardon me, Kevin) - fuck the NSA.

  That certainly is a fashionable pose to strike these days!

  But I brought up binding a 1024-bit FFC to a password because that's
what an RFC with your name on it does. So it makes sense to replace
"the NSA" in your sentence with "Trevor Perrin".

  Dan.




From ynir@checkpoint.com  Wed Dec 11 14:17:33 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE481AE0D6 for ; Wed, 11 Dec 2013 14:17:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level: 
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 gAyrSbkZC3Xs for ; Wed, 11 Dec 2013 14:17:31 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 287C31ADF52 for ; Wed, 11 Dec 2013 14:17:30 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rBBMHLCY010843; Thu, 12 Dec 2013 00:17:21 +0200
X-CheckPoint: {52A8E0E1-7-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.146]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 00:17:21 +0200
From: Yoav Nir 
To: Daniel Kahn Gillmor 
Thread-Topic: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
Thread-Index: AQHO9PKwvFEdHESyEEm0ZUd+bMkQKppNxnIAgAAZ0wCAABfOAIABARgAgAAiFBCAAE9YgIAAB4AA
Date: Wed, 11 Dec 2013 22:17:20 +0000
Message-ID: 
References:  <52A77DB4.7020501@gmx.net> <52A7935E.5020906@cs.tcd.ie> <87ob4o1dbd.fsf@alice.fifthhorseman.net> <52A87F00.7000304@cs.tcd.ie> <4613980CFC78314ABFD7F85CC302772121B21CE3@IL-EX10.ad.checkpoint.com> <52A8DE25.4070905@fifthhorseman.net>
In-Reply-To: <52A8DE25.4070905@fifthhorseman.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.139]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF TLS Working Group 
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 22:17:33 -0000

On Dec 11, 2013, at 11:50 PM, Daniel Kahn Gillmor  w=
rote:

> On 12/11/2013 10:16 AM, Yoav Nir wrote:
>> I think it's possible to get all the extension hiding we want in TLS 1.3=
, even while keeping BC with TLS 1.0 servers:
>>=20
>> 1. Client sends ClientHello without the problem extensions (ALPN, SNI). =
The record version is 3.1 (TLS 1.0), while the supported version is 3.4 (TL=
S 1.3).=20
>>=20
>> 2a. The server replies with TLS 1.3, and everything works as planned. Th=
e end.
>>=20
>> 2b. The server replies with TLS 1.0, and some certificate. The certifica=
te may or may not fit the site. Makes no difference for now.
>> 3b. The client completes the exchange, and immediately begins a renegoti=
ation
>> 4b. In this renegotiation, the versions offered are just TLS 1.0 to TLS =
1.2, and all extensions are present (though encrypted).
>> 5b. The renegotiation completes at TLS 1.0 with all extensions.
>=20
> This approach should work to hide all extensions in current versions of
> TLS as well, right?  But no one does it, as far as i know.

Not that I'm aware of either, but it's not that different from hiding clien=
t certificates by making the first handshake server-authenticated, and the =
second handshake mutually-authenticated. That is something that some server=
s do, and all the clients cooperate nicely.

> Do you know of any TLS client library which does this, or provides an
> option to do it without a bunch of manual intervention in the workflow
> of the TLS stack by the library user?  Do you think certain tools or
> users should be doing this now?

I've seen the client certificate hiding done with Apache and OpenSSL. I don=
't think any information in the TLS handshake is as sensitive as the user n=
ame in the certificate.

>=20
> Are there any extensions which require that their content must be
> identical across session resumption or across a re-handshake?

Not to my knowledge.

> If so, it doesn't seem like those extensions could be used in this
> re-handshake approach.
>=20
>=20
> 	--dkg
>=20
>=20


From trevp@trevp.net  Wed Dec 11 14:34:30 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BA31AE168 for ; Wed, 11 Dec 2013 14:34:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.208
X-Spam-Level: 
X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77] 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 j-Wf9R20ND0L for ; Wed, 11 Dec 2013 14:34:29 -0800 (PST)
Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id B90D61AE171 for ; Wed, 11 Dec 2013 14:34:28 -0800 (PST)
Received: by mail-we0-f178.google.com with SMTP id u57so7050021wes.23 for ; Wed, 11 Dec 2013 14:34:22 -0800 (PST)
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=kUvedCtaQd/44QO/GTv3qLTyRZRV3cgJ6HJPlHurhzk=; b=Z3sei0jt8t8WxikqQllz2L3NHax/dDLtJjLZ7XCuolQK6nPSNcJYicrqcDlFuGIHF5 DC6NEVYPwYznrqckDg8P8lp0Oz85oePrHHrqSmTAsxKF1VWmS9AiX38Va76G2/rzg73Q 6b3+MrwoycFI8CMMjWwB0hYyaaCJXpBru1ixtmg3WflO8gw5yUUQ2YMjQ6gybrGBTbdt wjK3WJ2E6BUsEtFLpJGW6g255WnJM68hc8IRhHunG64UyeUWj+1x06oolE9AluhyTlFW f1QaxvhrtMBGk+dnA+BXvEJnmYODDOuPCKCpYrmZqhe7xckw6NGIipSknLJUtP/t0Ukr HdOw==
X-Gm-Message-State: ALoCoQk9a0sgQ/sls1H3MlcDPRXgbkTleRBDf+fmO7hnI4WD4R5ZShhu5oVZ4Szs36XuIZWPYu5q
MIME-Version: 1.0
X-Received: by 10.180.187.72 with SMTP id fq8mr26393399wic.26.1386801262342; Wed, 11 Dec 2013 14:34:22 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Wed, 11 Dec 2013 14:34:22 -0800 (PST)
X-Originating-IP: [208.70.28.214]
In-Reply-To: <59b169e8fb0405cfef0cb4a397668d7d.squirrel@www.trepanning.net>
References:  <081a8a74fc0084dcff176b07a7502c93.squirrel@www.trepanning.net>  <59b169e8fb0405cfef0cb4a397668d7d.squirrel@www.trepanning.net>
Date: Wed, 11 Dec 2013 14:34:22 -0800
Message-ID: 
From: Trevor Perrin 
To: Dan Harkins 
Content-Type: text/plain; charset=ISO-8859-1
Cc: cfrg@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Review of Dragonfly PAKE
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 22:34:30 -0000

On Wed, Dec 11, 2013 at 2:07 PM, Dan Harkins  wrote:
>
> On Wed, December 11, 2013 11:50 am, Trevor Perrin wrote:
>> On Tue, Dec 10, 2013 at 5:35 PM, Dan Harkins  wrote:
> [snip]
>>>   It makes little sense to negotiate a 256-bit or even a 128-bit
>>> cipher or a hash algorithm with a 256-bit or 512-bit digest size
>>> when the domain parameter set is fixed to a 1024-bit FFC group.
>>> What makes sense is to allow for negotiation of a 4096-bit FFC
>>> group or a 256-bit ECC group along with your AES-GCM-128
>>> with key derivation using HMAC-256.
>>
>> It makes little sense to use a 1024-bit FFC group in any circumstances
>> because (pardon me, Kevin) - fuck the NSA.
>
>   That certainly is a fashionable pose to strike these days!
>
>   But I brought up binding a 1024-bit FFC to a password because that's
> what an RFC with your name on it does.

RFC 5054 has a range of DH groups.  I would've preferred not to
include the lower-strength ones.

Care to respond to any other points, or can we assume Dragonfly is
debunked at this point?


Trevor

From dharkins@lounge.org  Wed Dec 11 15:04:09 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFE11AE039; Wed, 11 Dec 2013 15:04:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 09LfUAuyO7T6; Wed, 11 Dec 2013 15:04:07 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 28DA21AE032; Wed, 11 Dec 2013 15:04:07 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4AE3C10224008; Wed, 11 Dec 2013 15:04:01 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 11 Dec 2013 15:04:01 -0800 (PST)
Message-ID: <2998cd451a359431a8c17a712b148f93.squirrel@www.trepanning.net>
In-Reply-To: 
References:  <081a8a74fc0084dcff176b07a7502c93.squirrel@www.trepanning.net>  <59b169e8fb0405cfef0cb4a397668d7d.squirrel@www.trepanning.net> 
Date: Wed, 11 Dec 2013 15:04:01 -0800 (PST)
From: "Dan Harkins" 
To: "Trevor Perrin" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: cfrg@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Review of Dragonfly PAKE
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 23:04:09 -0000

On Wed, December 11, 2013 2:34 pm, Trevor Perrin wrote:
> On Wed, Dec 11, 2013 at 2:07 PM, Dan Harkins  wrote:
>>
>> On Wed, December 11, 2013 11:50 am, Trevor Perrin wrote:
>>> On Tue, Dec 10, 2013 at 5:35 PM, Dan Harkins 
>>> wrote:
>> [snip]
>>>>   It makes little sense to negotiate a 256-bit or even a 128-bit
>>>> cipher or a hash algorithm with a 256-bit or 512-bit digest size
>>>> when the domain parameter set is fixed to a 1024-bit FFC group.
>>>> What makes sense is to allow for negotiation of a 4096-bit FFC
>>>> group or a 256-bit ECC group along with your AES-GCM-128
>>>> with key derivation using HMAC-256.
>>>
>>> It makes little sense to use a 1024-bit FFC group in any circumstances
>>> because (pardon me, Kevin) - fuck the NSA.
>>
>>   That certainly is a fashionable pose to strike these days!
>>
>>   But I brought up binding a 1024-bit FFC to a password because that's
>> what an RFC with your name on it does.
>
> RFC 5054 has a range of DH groups.  I would've preferred not to
> include the lower-strength ones.
>
> Care to respond to any other points, or can we assume Dragonfly is
> debunked at this point?

  Your post was a series of personal opinions that were caveated with
things like "I'm not qualified to assess this argument" and "Perhaps I'm
wrong." You restated your preference favoring augmented PAKEs for the
umpteenth time-- "I prefer the security benefit of augmented PAKE"--
and for the umpteenth plus one time-- "I think augmented PAKEs
are preferable." And you called dragonfly "gimmicky" and "a bad PAKE".

  I already responded to the points you raised originally. You replied with
a bunch of opinions. I'll just let those stand.

  Debunked? Ha ha. You sure think highly of yourself.

  Dan.




From brian@briansmith.org  Wed Dec 11 15:53:54 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD2C1AE154 for ; Wed, 11 Dec 2013 15:53:54 -0800 (PST)
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 XJCWaF5Wf3cp for ; Wed, 11 Dec 2013 15:53:53 -0800 (PST)
Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id EE2551AE207 for ; Wed, 11 Dec 2013 15:53:52 -0800 (PST)
Received: by mail-qa0-f41.google.com with SMTP id j5so5273124qaq.7 for ; Wed, 11 Dec 2013 15:53:47 -0800 (PST)
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=5L+MfzHA7ff0V6fZXsIZoXzlhoWreGNoXDt0pugtRAI=; b=UjQ2MJNq1lREoDrvI7hG4OVFMSXBS1mH30u8PhVtNp7AL+ZHLQ+cCyIfU5ykyNfyzN APucTiNiXOa83AuPsKKirhi5tCtpf76NrNZSekS/Zrd0zqkVxy9lUriuH3fiQSrDiQoa m7Xkyhm7B2nfm0ZIiyllKXl3xReSpz5ZeuIbphvkrefpP2wcVGiBUJtx4ss9dfW/HiFU 4SjfzeefSqiQYJ9b7kQva/f8LznG4Zu6sst+vbXWqYEIuyYeegkmrXLjKJnTMsUW1Lpi 6KeGABaWFNWZeOXnOpGRTFpnxxAYxFn4cJ9AkZNGvo32tcdVKHhfra3pRGBZxLk9RKUG bJ0Q==
X-Gm-Message-State: ALoCoQklHNNUsXk8mPISkd0FpqaUvxP4pV1T362o1d+TJBOfA1hV4plPtonCAuVdklN3kV6tBKWN
MIME-Version: 1.0
X-Received: by 10.229.127.193 with SMTP id h1mr450985qcs.14.1386806027091; Wed, 11 Dec 2013 15:53:47 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Wed, 11 Dec 2013 15:53:47 -0800 (PST)
X-Originating-IP: [63.245.219.54]
In-Reply-To: <4613980CFC78314ABFD7F85CC302772121B21CE3@IL-EX10.ad.checkpoint.com>
References:  <52A77DB4.7020501@gmx.net> <52A7935E.5020906@cs.tcd.ie> <87ob4o1dbd.fsf@alice.fifthhorseman.net> <52A87F00.7000304@cs.tcd.ie> <4613980CFC78314ABFD7F85CC302772121B21CE3@IL-EX10.ad.checkpoint.com>
Date: Wed, 11 Dec 2013 15:53:47 -0800
Message-ID: 
From: Brian Smith 
To: Yoav Nir 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: IETF TLS Working Group 
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 23:53:54 -0000

On Wed, Dec 11, 2013 at 7:16 AM, Yoav Nir  wrote:
> 2b. The server replies with TLS 1.0, and some certificate. The certificat=
e may or may not fit the site. Makes no difference for now.
> 3b. The client completes the exchange, and immediately begins a renegotia=
tion
> 4b. In this renegotiation, the versions offered are just TLS 1.0 to TLS 1=
.2, and all extensions are present (though encrypted).
> 5b. The renegotiation completes at TLS 1.0 with all extensions.
>
> This solves the issue of hiding extension. If TLS 1.3 is not supported by=
 the server, it means an extra handshake with all associated costs. It may =
be possible, if the server presented the correct certificate to have sessio=
n resumption with the renegotiation, although that is usually not recommend=
ed.

Thanks for trying to find a solution. However, it is not acceptable to
add any new round trips to hide information in the ClientHello, and
also we can't add whatever compatibility risk there would be in
depending on renegotiation (the compatibility issues with even initial
handshakes are a huge drain). If/when we have ~99% adoption of TLS 1.3
with encrypted ClientHello information, we could revisit this kind of
approach. But, that is several (10?) years away. Until then, we'd need
an approach that doesn't add any round trips to the handshake.

Keep in mind that if it were acceptable to add new round trips to the
handshake, we wouldn't need ALPN or NPN at all.

In fact, we don't need ALPN or NPN for the case of a 1-RTT handshake,
if we standardize a way to allow protocol-neutral prefixes of the
application data, like I showed at the end of this message:
http://www.ietf.org/mail-archive/web/tls/current/msg10888.html

Cheers,
Brian
--=20
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

From brian@briansmith.org  Wed Dec 11 15:59:54 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC181AE215 for ; Wed, 11 Dec 2013 15:59:54 -0800 (PST)
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 tDLq1xit0QUX for ; Wed, 11 Dec 2013 15:59:52 -0800 (PST)
Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2431AE210 for ; Wed, 11 Dec 2013 15:59:52 -0800 (PST)
Received: by mail-qc0-f180.google.com with SMTP id w7so5636722qcr.39 for ; Wed, 11 Dec 2013 15:59:46 -0800 (PST)
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=t4jfD7L/oirEilt8h8rN/9N37tqqYQAglxB+uLLLmf8=; b=aGtiqefUEWfxwp8ZGPukSgc1ll5UzKly337TaiDuFYoUxO2RFODl29XJngV1Futyxj ZO/hUYoR5TiWPz5ZnnEQuGLEDYoGBxy4gwN4CEOn+3y5GKxU4teL+ygJaftX9q1vdikm ZRYRx2UZlMQh6Ykp86EJBjH2W0zjUZS9gK4Dk9SM5WaAftVscRpsQovAyBC3kRamUv8C PkSq2ZPM39UtcNJxmf2WRWOPC5aqiEeZD3gf7l7BHidRy7RBKGLrxfZt6vsdpSL5bAZ8 Dcw0hr5v8+4xmZTuwJRNZk/VCzNCGLPLDbsk1NCwhSVfsehC+iSsCxBhJoGVOW0wa3oz U+Hw==
X-Gm-Message-State: ALoCoQmmWNJFWND8aKaMAswmU/njMx6q0KpEIuZ2uRQvRCaTy6pAKPBtm/7wUlacbvJmv1BgYWpa
MIME-Version: 1.0
X-Received: by 10.224.25.196 with SMTP id a4mr511520qac.31.1386806386668; Wed, 11 Dec 2013 15:59:46 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Wed, 11 Dec 2013 15:59:46 -0800 (PST)
X-Originating-IP: [63.245.219.54]
In-Reply-To: 
References: <87ob4o1dbd.fsf@alice.fifthhorseman.net> 
Date: Wed, 11 Dec 2013 15:59:46 -0800
Message-ID: 
From: Brian Smith 
To: Bill Frantz 
Content-Type: text/plain; charset=UTF-8
Cc: "" 
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 11 Dec 2013 23:59:54 -0000

On Wed, Dec 11, 2013 at 11:14 AM, Bill Frantz  wrote:
> We should not insist that a client using the new protocol be able to connect
> of a tls 1.2 server (or below) as a result of tls level negotiation. The
> fallback mechanisms in most browsers can cover that need. The extra design
> freedom will allow us to easily encrypt data that was previously sent in the
> clear without worrying about backward compatibility.

I think us browser people might have unintentionally misled people
about our eagerness to reconnect with downgraded security properties.
I, and other browser people I know, consider it mis-feature, and we'd
love to find a way to stop doing it. So, trying to connect via "TLS
2.0" that has better security/privacy properties, and then insecurely
falling back to TLS 1.2 with worse security/privacy properties, is
something that I'd definitely want to avoid.

There may be cases where the
connect-and-then-reconnect-with-different-parameters approach becomes
useful, but the key there is "different" and not "worse."

Besides being an ineffective security/privacy measure (since any MitM
could induce the fallback to from "TLS 2.0" to TLS 1.2), it would also
be unacceptable due to the added latency for any site that hadn't
upgraded to "TLS 2.0." We are many years away from that becoming a
viable thing for us to do.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

From watsonbladd@gmail.com  Wed Dec 11 16:02:06 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25251ADEAE for ; Wed, 11 Dec 2013 16:02:05 -0800 (PST)
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 sBFOr75M88ym for ; Wed, 11 Dec 2013 16:02:04 -0800 (PST)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 889571A8028 for ; Wed, 11 Dec 2013 16:02:04 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id m15so7129421wgh.25 for ; Wed, 11 Dec 2013 16:01:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O1zHKQY71dld+6dXdsOmPNz693IEvz/+pEyi4FenF0o=; b=Jtk6CogyNHURgWb9kqbBKkmXCuYlzULnFXwrzPcgwPFz1+IJvev1EAsIAv4BYfxNxT y3YTEZru8tQFbHWoy1qikA6gvEj7R0LVDQadkPh/EgWGFKUiaiDDU8bDXN1kI+1mNGq9 AY4DG65UAe83xgvp+JXitvY3HkhABjtN94LKL06ylDwg3V2jvjNFZWcQlXgExe4GR7lu +o2QcAtpRUmsqYd8z9JdAUIAmggF9SN2/FbgezkhcmxsRK8B+ppkkjQdfQd+ShzmDVDS TDbcEjJzZPwvgEYa2uMkw7BY+JlTet/+ntwga1xg6L3KLJRkuAahpP/DQEjSnHx7CYub osiA==
MIME-Version: 1.0
X-Received: by 10.180.73.6 with SMTP id h6mr5267328wiv.20.1386806518416; Wed, 11 Dec 2013 16:01:58 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Wed, 11 Dec 2013 16:01:58 -0800 (PST)
In-Reply-To: 
References:  <52A77DB4.7020501@gmx.net> <52A7935E.5020906@cs.tcd.ie> <87ob4o1dbd.fsf@alice.fifthhorseman.net> <52A87F00.7000304@cs.tcd.ie> <4613980CFC78314ABFD7F85CC302772121B21CE3@IL-EX10.ad.checkpoint.com> 
Date: Wed, 11 Dec 2013 16:01:58 -0800
Message-ID: 
From: Watson Ladd 
To: Brian Smith 
Content-Type: text/plain; charset=UTF-8
Cc: IETF TLS Working Group 
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 00:02:06 -0000

Can someone explain to me why "fuck you, make the protocol backwards
compatible" is not an acceptable response to those asking for
these things? The client has a perfectly fine way to send information
to the server, namely via the channel TLS establishes. Judging from
this and other threads, people want to make us do work that they can
do over the encrypted channel instead leading to all sorts of debates
over
what semantics are appropriate, and making it even hard to design a
next generation protocol to fix known problems.
Sincerely,
Watson Ladd

From brian@briansmith.org  Wed Dec 11 16:44:27 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B93D1ADF5A for ; Wed, 11 Dec 2013 16:44:27 -0800 (PST)
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 UbiLoHRxaEx6 for ; Wed, 11 Dec 2013 16:44:24 -0800 (PST)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42C711ADF86 for ; Wed, 11 Dec 2013 16:44:24 -0800 (PST)
Received: by mail-qa0-f44.google.com with SMTP id i13so5331038qae.17 for ; Wed, 11 Dec 2013 16:44:18 -0800 (PST)
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=bync8zIqrmORU8xrJ19ZWQiQTTwm/D9szTPCPYSkPV4=; b=bZBVd2RvB58FW3m8eL5UrXkHye4vSsaAfaVUKzzYPyMzISC18JGg+vFWdwm1hAyKnW E+QSCJvUu8jh/8rwJgqTdteXbv9Wdh3zk+VmO+D89SAPDmXdCh6oaWTcpgiifPzZw3z4 L6w5/xtQQWoDzzLFoLMs/go78R3Vt1jEZVp+WXJoteyl2MFT4etpk3yhoT81DrVrMFBF f1KtI/d9jK1xGe/4W6vN8OukmZsLMTCk5OQEnXVHY9x4NW9Tt+to+aSEerqeZ4S35sl8 /rhwVE49tOqApgparNas6paJXnIZZau/J63hxZ1v+gWndmZLKeKByAyMse69lNbP5h0D pTew==
X-Gm-Message-State: ALoCoQl3wg5Gy1MJ+jf68mWxT6jPuJ16hSiYrG7mzzQjTHdR+Y0K6qGLnNlgbvQ1cvJ7VbXVA8jW
MIME-Version: 1.0
X-Received: by 10.49.24.211 with SMTP id w19mr8207890qef.9.1386809058327; Wed, 11 Dec 2013 16:44:18 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Wed, 11 Dec 2013 16:44:18 -0800 (PST)
X-Originating-IP: [63.245.219.54]
In-Reply-To: <52A87F00.7000304@cs.tcd.ie>
References:  <52A77DB4.7020501@gmx.net> <52A7935E.5020906@cs.tcd.ie> <87ob4o1dbd.fsf@alice.fifthhorseman.net> <52A87F00.7000304@cs.tcd.ie>
Date: Wed, 11 Dec 2013 16:44:18 -0800
Message-ID: 
From: Brian Smith 
To: Stephen Farrell 
Content-Type: text/plain; charset=UTF-8
Cc: IETF TLS Working Group 
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 00:44:27 -0000

On Wed, Dec 11, 2013 at 7:04 AM, Stephen Farrell
 wrote:
> On 12/10/2013 11:44 PM, Daniel Kahn Gillmor wrote:
>> On Tue 2013-12-10 17:19:10 -0500, Stephen Farrell wrote:
>>> FWIW, I agree with you in general, but in this case the privacy
>>> leak is non-existent if its only HTTP/1.1 vs HTTP/2.0 - since the
>>> binary encoding and lack of head-of-line blocking in the latter
>>> will give that game away anyway.
>>
>> i don't think i understand this argument.  are you saying that
>> traffic analysis will disclose what protocol is in use in this
>> case?
>
> I believe so, esp since there's just http/1.1 and http/2.0 in
> question (well, maybe spdy too for some time).

Hi Stephen,

You made this argument in two different threads, and I'll just reply
in this one.

I am not concerned about a MitM learning whether you are talking
HTTP/1 vs HTTP/2 vs. SPDY. If ALPN were only capable of disclosing
which version of HTTP you are speaking, I'd not be objecting so
strongly to it.

However, the ALPN draft [0] isn't HTTP-specific. It happens to be the
case that only HTTP-related protocol identifiers are currently planned
to be registered, but that doesn't mean that HTTP is the only use case
for protocol negotiation.

One of my goals is to make it possible for an email server to
multiplex HTTP, SMTP, LDAP, IMAP, and/or POP all over port 443 on the
same host (with one hostname). So, for example, when a MitM sees a
connection to example.org:443, the MitM doesn't know which of those
protocols are being used, without doing traffic analysis. Then, the
next step is to add features to TLS to make traffic analysis much more
expensive and/or potentially impossible. I have talked to one large
email provider already about doing the first part (multiplexing all
email protocols over 443), and I got a pretty positive response. I
don't know if they would be willing to do the second part to make
traffic analysis difficult. But, I think email providers of the
Lavabit-like predisposition *would* be likely to consider adopting
anti-traffic-analysis features, because those features are likely to
be somewhat expensive in terms of bandwidth used.

I think doing more to prevent traffic analysis in the messaging space
(including, but not limited to, email) is a very important part of the
perpass effort. Without it, we help enable attackers with global
resources to infer social networks through traffic analysis, even when
the traffic is encrypted. By making it difficult for an adversary to
determine when you are sending a message, and when you are receiving a
message, we make their inference much harder and hopefully
impractical.

Again, if the ALPN extension in the ClientHello was empty and meant "I
prefer HTTP/2 if you support HTTP" then I wouldn't have any objection.
However, currently the ALPN extension effectively allows arbitrary
application data to be sent in the clear, even though it is intended
to only allow protocol negotiation. We've already seen how, in the
case of http2-tls-relaxed, it is tempting to extend ALPN in ways we're
not intended it to be used, with negative results. I object to that,
because it isn't safe.

I also support NPN is because it has a much higher safety margin.
Again, you can see the additional safety margin that NPN has over ALPN
by looking at the analysis of the http2-tls-relaxed I did. Although we
seem to all agree that negotiating http2-tls-relaxed is an unsound
idea in general, the point still stands that encrypting the
information in the handshake provided defense-in-depth against a
serious issue.

> If hiding that
> somewhat is the claimed benefit and if that diverted scarce
> WG resources away from tls1.3 then I figure doing the work
> in tls1.3 is better.

Actually, standardizing NPN would speed up the adoption of TLS 1.3,
because we wouldn't waste time trying to encrypt ALPN. We may want to
change how NPN works in TLS 1.3, and I am all for that. However, after
thinking about all the possibilities I could come up with, ultimately
if we're going to encrypt the protocol negotiation information in TLS
1.3, the negotiation will have to work more like NPN (server offers
protocols, client chooses one) than ALPN (client offers protocols,
server chooses one). So, adopting ALPN now, and then trying to fix
ALPN in TLS 1.3, would mean that browsers would go from NPN to ALPN
back to something very much like NPN. So, if anything is slowing down
work on TLS, it is actually ALPN itself.

> I really like the idea of meeting that requirement. But again
> it seems to me like it'd be better baked into tls1.3 and not
> done as an extension to tls1.2 or earlier.

I think it is likely that all of "TLS 1.3" will be effectively a set
of extensions to TLS 1.2 and earlier anyway. One reason is that we've
already seen evidence of widespread intolerance to version 0x0304 in
the ClientHello: 10% of hosts surveyed, according to [1]. The second
reason is that it is easier to prototype new features as extensions
than trying to implement everything all at once. The third reason is
that some people already have plans to backport at least some "TLS
1.3" features to earlier versions.

> My reasoning there
> assumes that we figure tls1.3 will be widely deployed more
> quickly than previous updates due to the collective win of
> running http/2.0 over tls1.3. Doing a lot of things in both
> tls1.3 and as extensions to earlier versions also seems less
> likely to work out, given that we all have limited cycles.
>
> But yes, that's prediction with which one could disagree.

I think your prediction is accurate, in that TLS 1.3 deployment will
be much faster than TLS 1.2 deployment. However, I doubt TLS 1.3
deployment will be widespread enough any time in the next 5-10 years
for browsers to be willing to degrade performance or security when
falling back to TLS 1.2 and earlier. That means we should plan on 10+
years of unencrypted ALPN in the ClientHello from all major browsers,
if we standardize unencrypted ALPN now.

[0] tools.ietf.org/html/draft-friedl-tls-applayerprotoneg-02
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=733647#c48

Cheers,
Brian

>> And protocol negotiation is not only useful in the
>> HTTP/1.1?HTTP/2.0 use case.
>>
>>> I'd say focusing on tls1.3 and any privacy gains there is better
>>> than diverting effort to NPN to be honest.
>>
>> The concern raised by Brian Smith is that if TLS 1.3 is an upgrade
>> to TLS 1.2 with cleartext ALPN, based on how we understand
>> negotiated TLS today, then compliant clients may have a strong
>> incentive to continue to send cleartext ALPN, so that they can
>> negotiate with servers not yet capable of TLS 1.3.
>
> Yep, that is a good question to consider. I don't think I've seen
> it addressed either, but maybe I missed that.
>
>> If we settle on ALPN now, the information in ALPN seems likely to
>> remain in the clear for lots of handshakes even after TLS 1.3 is
>> widely deployed.  If one of the goals of TLS 1.3 is encrypting as
>> much of the handshake as possible (which i think it should be),
>> then standardizing ALPN now seems to work against the goals of TLS
>> 1.3 more strongly than any diversion of effort related to NPN.
>
> Depends on what ALPN values would be present in a case where tls1.3
> and http/2.0 are supported. I don't know what'd be likely there.
>
> S.
>
>>
>> --dkg
>>
>>
>>
>> _______________________________________________ TLS mailing list
>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iQEcBAEBAgAGBQJSqH77AAoJEC88hzaAX42illgIAJltllnhLB3xGbHF/l6ul3nU
> Mzd8kvF9W27zRoGg0L1noxfQEawGyOjfRFxGXVO3BYHvXMSIfpAOC5vKWPnY/Hlc
> T2ZkklFk9bTq/b7PIJlmSlPTPqBBUCHlZkxxzlO5GeGwjXahOS7M+kc20/ufMHKG
> UGScMtzV5cx3fDQBAPBXjU5w9WHNz0LnLrti9q682g11a4nyRNKvPuaa8ujr4Ona
> dDtGKIk6ITr6DthO5IrhTEdRpR9/AgpR8WrXslMTKldELw6Inf4dBKOOkOJtnptA
> OTbtozBtlyvMQCHSxoVEb0FS5AgXFvTVL9t3SY/1BcYmzvbjvYl/XP1kNI8VTS4=
> =JATC
> -----END PGP SIGNATURE-----
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

From brian@briansmith.org  Wed Dec 11 16:58:24 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3201AE0DE for ; Wed, 11 Dec 2013 16:58:24 -0800 (PST)
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 79Z37FN20rlR for ; Wed, 11 Dec 2013 16:58:22 -0800 (PST)
Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 72ACE1AD791 for ; Wed, 11 Dec 2013 16:58:22 -0800 (PST)
Received: by mail-qc0-f180.google.com with SMTP id w7so5792320qcr.11 for ; Wed, 11 Dec 2013 16:58:16 -0800 (PST)
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=eAUpEMXk2qVtyEHfe7fdAfJso2itdHyOXRdrsxdrhRI=; b=Q5LBYw3qLxNPKtlwAD3LHvYG9MTJJ7qjrNFYUpVetzLTmUPrGKrais+vRnwhlvnCXc CNWeZC4T8LR6FwLtv0hs32Q8fN5u/ojCo9iTTOD4wIVN5mSDA7iPAG3tFAK5BxJyrdTY wuHQOWNQuDnEAseGaqba25gWOUr8nCzoFLENmN0pP27yAINolGSo2cJJkLE2FumDWC4+ Ml8/NRPcD2oPjCZT2ju3A8QVDjGwwKXgy9P6pRO5oDuh85we3qBSm107mpqC+6mNrm7I SmBtCo2UwVU1eoKDT5QvYl3tbkvWJTGIVPyqVUlGsoQVdoA4auLH+xnlKqFHFl9hKGMN CHvQ==
X-Gm-Message-State: ALoCoQnuZ++U0KLhymmSYnfWEXwE/G4tQOytuXSrW48OlOwEzUXlmom5iiWBg/XLyYWmDiiBS/5h
MIME-Version: 1.0
X-Received: by 10.224.171.196 with SMTP id i4mr886329qaz.38.1386809896541; Wed, 11 Dec 2013 16:58:16 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Wed, 11 Dec 2013 16:58:16 -0800 (PST)
X-Originating-IP: [63.245.219.54]
In-Reply-To: 
References:  
Date: Wed, 11 Dec 2013 16:58:16 -0800
Message-ID: 
From: Brian Smith 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Cc: "" 
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 00:58:24 -0000

On Tue, Dec 10, 2013 at 10:30 PM, Eric Rescorla  wrote:
> After reviewing your request, the chairs believe that it does not raise any
> new substantive issues that were not known to the WG at the time of the
> decision to adopt ALPN and the subsequent WGLC. Therefore, we do not
> believe it is appropriate to re-open the issue at this time.
>
> Because the document has already passed WGLC, we will be asking the
> AD for advancement. You should of course feel free to reraise your objections
> during IETF LC.

Thanks for the response Eric.

I can understand that the chairs may not think it is appropriate to
re-open the issue at this time. It isn't surprising, because you have
lobbied for ALPN and against NPN, and you've also said that it is
important for Cisco (the other chair's employer) to have its
inspection appliances capable of learning which protocol is being used
on TLS connections.

But, don't you think it would be better for the whole working group to
make that determination, instead of just the chairs? I think that if
you simply asked the working group if we (still) have have a
consensus, and the consensus is "go ahead with ALPN," then the whole
issue would be resolved within a week or two, and there would be no
trouble with IETF LC. But, if we don't verify that we actually have a
consensus now, then during IETF LC there will be doubt about whether
we still have a consensus.

I remember somebody once saying that, when we have authority, it is
important to avoid not just impropriety, but also the *appearance* of
impropriety. We as a working group have the authority and
responsibility to everybody that uses IETF protocols and products
based on TLS to make sure we've made good decisions and achieved
consensus. So, I still think it is important, before advancing the
document to IETF LC, that we clarify and verify that we actually have
a consensus.

Thanks again,
Brian

From wtc@google.com  Wed Dec 11 17:21:55 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1201ADF95 for ; Wed, 11 Dec 2013 17:21:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 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.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 eZlR0skpXKbt for ; Wed, 11 Dec 2013 17:21:54 -0800 (PST)
Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 70E811ADBD4 for ; Wed, 11 Dec 2013 17:21:54 -0800 (PST)
Received: by mail-ve0-f172.google.com with SMTP id jw12so6634784veb.31 for ; Wed, 11 Dec 2013 17:21:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V58d3t9rq88P9vcJ0GZAkswWZ4w92rwaPglpfvtB6GA=; b=PkiKHvvZwEK4KwmnL0WGLqPutD5DStIfwOJPT5Em313ioGqjuWsDAdSlUNB7eOGhBn oXo9tiQuaZ5nY2bVkfLiJLiL3GZ3YjgsaNAzUjDQPKACzePlg/cexmZp8BVzDwuPdNxO 87t+K3A6y70d0NMJKdMbLIwCaBFb8Eh3n1kpFcOrLj2+zmBnaoMTfvobhr+3tTQ10i6v YLbYIWVzfk+DufES563xHWVLvaRvWJpEdh6u4SHneJCXtTMZCytGrszCbso+5PTBD9Ul 6ZIVo4bJTv+P7fmQW/rOt5jiaYDDXZqoVoJuMDqLd3kj7h73KxcZJzgtn68r6Wi7UtoH fC0A==
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=V58d3t9rq88P9vcJ0GZAkswWZ4w92rwaPglpfvtB6GA=; b=D6bQDtyciT2ptm8ptT68XQIFlgL4Ql1TDU3+0v5E5edyk9HvgM6dC0TLj2ZSOLDoFc 9ITldZn+qg/0nNMJPXUD8UkjkyBg6dHZjkQsdrAw2reWC21Tv/K4WzNmF4qHc4OyJ1tU cBVdLgWQCUJw2i/uKxcqlGZMIzMDRpcA6B+4Y9Edssgf85ZLCMRxZ1HIj8C/B0nm0+Sx GF/VE9+QpfA5UNwNAc5WotwqVSTDjboQOWO2viQbf+BBpmbrDNOJMjO20JicwDTXbivc gD3sw5XXEeTcC4iBa/2t8RLJsYN7wERjgqdJwulkjD3nW6pLZQig5cjG0kXa9k1zsI2c soqg==
X-Gm-Message-State: ALoCoQmZ8dEycbpvvXyT/WFBL7728UH6lV4maZZhby0c3xrgVRvj2fpe57PrfZepxRISqM1/BHxhi4h4c+pOxbloKFoI5UCEQwt5z6xZcTvR2W4/9wb5vUcKLKHZ+LXTeBb2fU+115Rt6vhGliiyz1P71/ikbfSyhHZNYg4W8QvVa9VsEQ+TMXS+OPLXYzkhyUpei4rw6D+D
MIME-Version: 1.0
X-Received: by 10.220.194.133 with SMTP id dy5mr1936354vcb.3.1386811308501; Wed, 11 Dec 2013 17:21:48 -0800 (PST)
Received: by 10.52.167.10 with HTTP; Wed, 11 Dec 2013 17:21:48 -0800 (PST)
In-Reply-To: 
References:   
Date: Wed, 11 Dec 2013 17:21:48 -0800
Message-ID: 
From: Wan-Teh Chang 
To: Brian Smith 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" 
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 01:21:55 -0000

Brian,

To me, the ALPN vs. NPN debate is like emacs vs. vi and Linux vs.
FreeBSD. We can talk passionately about it forever, but at some point
we need to make a decision and move on.

On Tuesday, Nov. 5, 2013 I was in the two sessions at IETF 88
Vancouver where ALPN was discussed. I witnessed several people spoke
in support of you after you spoke at the TLS WG session. The strange
thing is that some of those people also attended the httpbis WG
session that morning and heard Stephan Friedl's presentation of ALPN,
but none of them raised any objection then. This seems to imply they
were also willing to accept ALPN, until you tried to reopen the issue.

Wan-Teh Chang

From paul.hoffman@vpnc.org  Wed Dec 11 18:44:14 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463F61ADFA0 for ; Wed, 11 Dec 2013 18:44:14 -0800 (PST)
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 dlpctA1djcv0 for ; Wed, 11 Dec 2013 18:44:13 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6B29E1AD8EE for ; Wed, 11 Dec 2013 18:44:13 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rBC2i4Ew027538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Dec 2013 19:44:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman 
In-Reply-To: 
Date: Wed, 11 Dec 2013 18:44:04 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <7B28991B-5377-433D-875B-DD3CE2FE7744@vpnc.org>
References:    
To: Wan-Teh Chang 
X-Mailer: Apple Mail (2.1822)
Cc: "" 
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 02:44:14 -0000

On Dec 11, 2013, at 5:21 PM, Wan-Teh Chang  wrote:

> but none of them raised any objection then. This seems to imply they
> were also willing to accept ALPN, until you tried to reopen the issue.

Some people said to me that they were "willing" because the TLS chairs =
so forcefully pushed the WG in one direction, there was no reason to =
discuss it any further. The chair's message from yesterday despite the =
large number of voices in support of re-opening makes that resignation =
seem more appropriate.

--Paul Hoffman=

From watsonbladd@gmail.com  Wed Dec 11 18:51:24 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462EE1AE12C for ; Wed, 11 Dec 2013 18:51:24 -0800 (PST)
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 HWzs8MlLfPmG for ; Wed, 11 Dec 2013 18:51:22 -0800 (PST)
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 34E7C1AE0AD for ; Wed, 11 Dec 2013 18:51:22 -0800 (PST)
Received: by mail-wi0-f175.google.com with SMTP id hi5so8022525wib.2 for ; Wed, 11 Dec 2013 18:51:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wyab9rsqIN0SdK1+PjlMWR5lYAMZUUWZZgPyFDKfHyA=; b=HvoaSjWlgdvcVLADN3i8IHzmX5h5VvQp3WH+QNpMlE+lOiiabYnhtb9vqYE82Q89bT kVICBjWLi4xEUyq4yoBPMU5rOuiWw3/EUjOcWoorlSdtV5gCMJSrqyqVBPkC298tFShz Uvk2WVGuOknOqYtMfyqTzm/8klF4T8SFqF7ooRNLxKAs80sfF0Vwbui1JZVsjC7EXjrJ vXvj6KgXo76z6kJRrnHLrYAIx7WDPcKovDwYEcKkWqk4sk/DhfAxGQTdtdPGfuw71anj WXtLYmPv4yqRBGbZrJxPt2wGMLEYs9MKhJ9dtbml65doryr5rZgFYZ70z/aiyeyZdWun ENTQ==
MIME-Version: 1.0
X-Received: by 10.180.7.136 with SMTP id j8mr27454115wia.17.1386816676056; Wed, 11 Dec 2013 18:51:16 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Wed, 11 Dec 2013 18:51:15 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Wed, 11 Dec 2013 18:51:15 -0800 (PST)
In-Reply-To: <7B28991B-5377-433D-875B-DD3CE2FE7744@vpnc.org>
References:     <7B28991B-5377-433D-875B-DD3CE2FE7744@vpnc.org>
Date: Wed, 11 Dec 2013 18:51:15 -0800
Message-ID: 
From: Watson Ladd 
To: Paul Hoffman 
Content-Type: multipart/alternative; boundary=14dae9cdc8ff5857d904ed4d6b8f
Cc: tls@ietf.org
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 02:51:24 -0000

--14dae9cdc8ff5857d904ed4d6b8f
Content-Type: text/plain; charset=UTF-8

On Dec 11, 2013 6:44 PM, "Paul Hoffman"  wrote:
>
> On Dec 11, 2013, at 5:21 PM, Wan-Teh Chang  wrote:
>
> > but none of them raised any objection then. This seems to imply they
> > were also willing to accept ALPN, until you tried to reopen the issue.
>
> Some people said to me that they were "willing" because the TLS chairs so
forcefully pushed the WG in one direction, there was no reason to discuss
it any further. The chair's message from yesterday despite the large number
of voices in support of re-opening makes that resignation seem more
appropriate.
And yet fixing Lucky 13, killing RC4 weren't on the agenda where chairs
were willing to push. Cui bono?
>
> --Paul Hoffman
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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




On Dec 11, 2013 6:44 PM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:

>

> On Dec 11, 2013, at 5:21 PM, Wan-Teh Chang <wtc@google.com> wrote:

>

> > but none of them raised any objection then. This seems to imply t=
hey

> > were also willing to accept ALPN, until you tried to reopen the i=
ssue.

>

> Some people said to me that they were "willing" because the =
TLS chairs so forcefully pushed the WG in one direction, there was no reaso=
n to discuss it any further. The chair's message from yesterday despite=
 the large number of voices in support of re-opening makes that resignation=
 seem more appropriate.


And yet fixing Lucky 13, killing RC4 weren't on the agenda where chairs=
 were willing to push. Cui bono?

>

> --Paul Hoffman

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

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




--14dae9cdc8ff5857d904ed4d6b8f--

From ekr@rtfm.com  Wed Dec 11 18:59:23 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DE01AE1C5 for ; Wed, 11 Dec 2013 18:59:23 -0800 (PST)
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 nb3LMWvDbrtO for ; Wed, 11 Dec 2013 18:59:21 -0800 (PST)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 92A571ADFA0 for ; Wed, 11 Dec 2013 18:59:21 -0800 (PST)
Received: by mail-wi0-f174.google.com with SMTP id z2so8036378wiv.1 for ; Wed, 11 Dec 2013 18:59:15 -0800 (PST)
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=1LN4WsWBf1C7ceb7wpldsfjARlMvxed1ExQBjfom260=; b=OJG1yYhrqQ0jrzpIubPwx1VEpwFftWSSNS4+Lir3yffxAHvplR4hrQuheWVFYzKUGZ Vol+NYAefkaS78ngRX7g6AZ6LwLbPEFpoS/BVIYyAQ0rJKmC0gIVk89eGvSMu5OND+Mi xPcV2K7S6ezo0IPbUvWq5p2taOmzYYWCDC0c3BfsmnQ2S1zWtoLf63yEYLzXeAOuo8GG sUsyM9m4GCxvy4E/bGRe0T5XzIBW+RXw1f7AuYmegADHhjgOuxwPh9wBLlkS5zRiKbRJ ueFwyrO27e+avNdVaLL2p47ZKyAczkPoxoG9jm6F+JBfd0JI3XoRb5a58mkINT+piIeC 5wfw==
X-Gm-Message-State: ALoCoQk/rRnjGRkt3DiakJGjbu3tUwZFv64WQ+KyQy9RhSEtj77ReancNZFJRGRQE8c4Ka/qaziz
X-Received: by 10.194.240.197 with SMTP id wc5mr4230210wjc.23.1386817155440; Wed, 11 Dec 2013 18:59:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Wed, 11 Dec 2013 18:58:35 -0800 (PST)
X-Originating-IP: [118.163.10.190]
In-Reply-To: 
References:   
From: Eric Rescorla 
Date: Thu, 12 Dec 2013 10:58:35 +0800
Message-ID: 
To: Brian Smith 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" 
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 02:59:23 -0000

Brian,

You write:

  But, don't you think it would be better for the whole working group to
  make that determination, instead of just the chairs? I think that if
  you simply asked the working group if we (still) have have a
  consensus, and the consensus is "go ahead with ALPN," then the whole
  issue would be resolved within a week or two, and there would be no
  trouble with IETF LC.

This is the purpose served by the WGLC, which ended in September.
You are asking for yet another call for consensus; this would be appropriate
if there were materially new information available to the WG which
became available after WGLC (otherwise, people could just keep
asking for consensus calls).  Whether this is in fact the case is a
question for the chairs and the ADs.

We consulted with the AD prior to taking this action, so perhaps he
will respond to you separately.

-Ekr


On Thu, Dec 12, 2013 at 8:58 AM, Brian Smith  wrote:
> On Tue, Dec 10, 2013 at 10:30 PM, Eric Rescorla  wrote:
>> After reviewing your request, the chairs believe that it does not raise any
>> new substantive issues that were not known to the WG at the time of the
>> decision to adopt ALPN and the subsequent WGLC. Therefore, we do not
>> believe it is appropriate to re-open the issue at this time.
>>
>> Because the document has already passed WGLC, we will be asking the
>> AD for advancement. You should of course feel free to reraise your objections
>> during IETF LC.
>
> Thanks for the response Eric.
>
> I can understand that the chairs may not think it is appropriate to
> re-open the issue at this time. It isn't surprising, because you have
> lobbied for ALPN and against NPN, and you've also said that it is
> important for Cisco (the other chair's employer) to have its
> inspection appliances capable of learning which protocol is being used
> on TLS connections.
>
> But, don't you think it would be better for the whole working group to
> make that determination, instead of just the chairs? I think that if
> you simply asked the working group if we (still) have have a
> consensus, and the consensus is "go ahead with ALPN," then the whole
> issue would be resolved within a week or two, and there would be no
> trouble with IETF LC. But, if we don't verify that we actually have a
> consensus now, then during IETF LC there will be doubt about whether
> we still have a consensus.
>
> I remember somebody once saying that, when we have authority, it is
> important to avoid not just impropriety, but also the *appearance* of
> impropriety. We as a working group have the authority and
> responsibility to everybody that uses IETF protocols and products
> based on TLS to make sure we've made good decisions and achieved
> consensus. So, I still think it is important, before advancing the
> document to IETF LC, that we clarify and verify that we actually have
> a consensus.
>
> Thanks again,
> Brian

From TurnerS@ieca.com  Wed Dec 11 20:29:08 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8220B1ADF7C for ; Wed, 11 Dec 2013 20:29:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.133
X-Spam-Level: *
X-Spam-Status: No, score=1.133 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] 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 Cc8cr_4R5GRq for ; Wed, 11 Dec 2013 20:29:07 -0800 (PST)
Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.56.148.12]) by ietfa.amsl.com (Postfix) with ESMTP id F377C1ADF4F for ; Wed, 11 Dec 2013 20:29:06 -0800 (PST)
Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 0A5A81F816E8; Wed, 11 Dec 2013 22:29:01 -0600 (CST)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway13.websitewelcome.com (Postfix) with ESMTP id E26A01F8167A for ; Wed, 11 Dec 2013 22:29:00 -0600 (CST)
Received: from [198.180.150.142] (port=52060 helo=v142.vpn.iad.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VqxtU-0005DS-5t for tls@ietf.org; Wed, 11 Dec 2013 22:29:00 -0600
From: Sean Turner 
Content-Type: multipart/signed; boundary="Apple-Mail=_7DB6A978-AD98-4025-A646-23E3D5896053"; protocol="application/pkcs7-signature"; micalg=sha1
Message-Id: <96BC541D-11CF-4957-AEF5-902C34F8A73B@ieca.com>
Date: Wed, 11 Dec 2013 20:28:57 -0800
To: tls@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
X-Mailer: Apple Mail (2.1822)
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: 198.180.150.142
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (v142.vpn.iad.rg.net) [198.180.150.142]:52060
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Subject: [TLS] ALPN Progression
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 04:29:09 -0000

--Apple-Mail=_7DB6A978-AD98-4025-A646-23E3D5896053
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

All,

Based on the information at hand and the numerous conversations I=92ve =
had with the chairs on this topic, I=92m planning to issue an IETF LC =
for this draft.  I agree with the chairs that Brian's message does not =
raise any new substantive issues that were not known to the WG at the =
time of the decision to adopt ALPN.

spt


--Apple-Mail=_7DB6A978-AD98-4025-A646-23E3D5896053
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww
ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE
ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT
AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn
tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb
ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg
wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4
rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB
njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD
VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll
Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB
CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE
kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1
N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th
GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i
Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ
v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE
eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi
/aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48
OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM
MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C
CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTEzMTIxMjA0Mjg1N1owIwYJKoZIhvcNAQkEMRYEFDaNviFDTaQliWrKnBbaZZSC
Hq6vMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C
CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF
Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQDlTJQxgeP76FAimFcluYJC8tW8
PqsITEGIB3pQNRkQY7gT28KAWtiOYpzUH5k0V9Q6HcDrQXLnHwjyJ82l5pn6R067kKjUGOtIQjf8
wexpwFfcIbNEv5DUvhfvDYTzZTpphz3UyUKkToUSFoTTV37TpPWOQNwXlvn+RT/OuFO8vp7xvC6Y
/giGElq6jPlEc23ExYPRScPg0vmct2DZJ1SZwfgfGUlxuh7Tt3Go9LfNVyuaWe4COC1ZrAGIIGlW
ZIlIt93sxv0r84r2viCvq9XbeRMU1GIJLTsfyz6GC5cKVoj5VRl+zbx1sCfjo2ZnYiNQHUgVeL2A
igu6j5Me1nJBAAAAAAAA

--Apple-Mail=_7DB6A978-AD98-4025-A646-23E3D5896053--

From mnot@mnot.net  Wed Dec 11 22:40:16 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2001AE172 for ; Wed, 11 Dec 2013 22:40:16 -0800 (PST)
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 bKJGbLFCb0E1 for ; Wed, 11 Dec 2013 22:40:14 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 63EB11AE125 for ; Wed, 11 Dec 2013 22:40:14 -0800 (PST)
Received: from [192.168.1.55] (unknown [118.209.35.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 25E7622E253; Thu, 12 Dec 2013 01:40:01 -0500 (EST)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Thu, 12 Dec 2013 17:39:56 +1100
To: "tls@ietf.org list" , HTTP Working Group 
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
X-Mailer: Apple Mail (2.1822)
Subject: [TLS] FYI: Using ALPN protocol IDs in Web Perf specs
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 06:40:16 -0000

Just so folks know -- as a member of the W3C Web Performance WG, I've =
made a proposal to identify the protocol in use with the =
NavigationTiming and ResourceTiming specs using the ALPN protocol =
identifier; see:
  http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0090.html

Note the language about non-UTF-8 identifiers.

You can find out more about those specs here:
  http://www.w3.org/2010/webperf/

Cheers,

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




From skyper@thc.org  Thu Dec 12 05:32:23 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE251AE281 for ; Thu, 12 Dec 2013 05:32:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.357
X-Spam-Level: 
X-Spam-Status: No, score=-0.357 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, MISSING_HEADERS=1.021, 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 oVmz-vJUDiVM for ; Thu, 12 Dec 2013 05:32:20 -0800 (PST)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id A50A31AD958 for ; Thu, 12 Dec 2013 05:32:20 -0800 (PST)
Received: by mail-ie0-f181.google.com with SMTP id e14so509896iej.26 for ; Thu, 12 Dec 2013 05:32:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=9nQBobhK69/KotEXga/kZyZ79PKCcUi0J7xRS+97nrE=; b=OEKECERH5kziGMsgZ+ZWQRe3ufHKM8fSOj6ub+uaWymqxZvsuUozp+j/Xh34xFfLD9 VpJKhGRaylXuZXz3QDtyWlGo8kafC0fcwWJXXcmimz+aF84161SS3TcvjDdnvejEukC9 FYKj88+5xhb829gsOGeavF0OJAVzMo++Prvu8=
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:cc:content-type; bh=9nQBobhK69/KotEXga/kZyZ79PKCcUi0J7xRS+97nrE=; b=ILot3viuVCnEL87JHPSPChX9rVtzXf8IMwjzfFVZdVVS8C1lsiaNYXneNHBNJiimLI xiNDezCKKGAa0pMYuOzskt8UVMVQpOd5P/MvUBocHDP7n4HlZ5LkhwQezKNeoIe2AhbK mb5hjErN5p6kJ1pdW+MiKgRc0jurV4Rp6WMUUnQX8WsktqxQu24uap53c6A6eI2eeUmg I2ai78VHvnoLKtXg+G8/FDJSz08tzXlyC67vBP0k/lcNd/4M2zQ7VB721WIvzK/5rVH5 U2wxk7ZVWC5apyFdPJPY7gkyW/nTWNWyabFTLdhx0AGu9OA3sHaqmEcpnelwyF4M7vpq YJDQ==
X-Gm-Message-State: ALoCoQnD7TtJ1u6fx+s4TW9aGgytgKz2wGNUfbLa9rhhxudeWxrtFk+lJF2OcBfyiJdhz1o3+ez2
MIME-Version: 1.0
X-Received: by 10.50.25.129 with SMTP id c1mt38793677igg.23.1386855134622; Thu, 12 Dec 2013 05:32:14 -0800 (PST)
Received: by 10.64.9.41 with HTTP; Thu, 12 Dec 2013 05:32:14 -0800 (PST)
X-Originating-IP: [81.156.248.122]
In-Reply-To: 
References:    
Date: Thu, 12 Dec 2013 13:32:14 +0000
Message-ID: 
From: Ralf Skyper Kaiser 
Content-Type: multipart/alternative; boundary=047d7bdc10eca8a6ea04ed565fa3
Cc: "" 
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 13:32:23 -0000

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

(not taking any sides but stating how it looks like. I personally do not
favor one over the other)

Hi Eric,


"if there were materially new information available to the WG"

I think Brian made a good case that 'materially new information is
available to the WG which became available after the WGLC'.
(This is where the chairs disagrees with Brian and others on the list).

It appears you are pushing ahead with something that the majority in the WG
does not agree with _today_. (They might have agreed
with it when the WGLC happened but they no longer agree - because of new
information which became available).

Nobody is saying that ALPN should be shelved. What people like to see is to
have a vote at IETF89 I guess.

regards,

ralf




On Thu, Dec 12, 2013 at 2:58 AM, Eric Rescorla  wrote:

> Brian,
>
> You write:
>
>   But, don't you think it would be better for the whole working group to
>   make that determination, instead of just the chairs? I think that if
>   you simply asked the working group if we (still) have have a
>   consensus, and the consensus is "go ahead with ALPN," then the whole
>   issue would be resolved within a week or two, and there would be no
>   trouble with IETF LC.
>
> This is the purpose served by the WGLC, which ended in September.
> You are asking for yet another call for consensus; this would be
> appropriate
> if there were materially new information available to the WG which
> became available after WGLC (otherwise, people could just keep
> asking for consensus calls).  Whether this is in fact the case is a
> question for the chairs and the ADs.
>
> We consulted with the AD prior to taking this action, so perhaps he
> will respond to you separately.
>
> -Ekr
>
>
> On Thu, Dec 12, 2013 at 8:58 AM, Brian Smith  wrote:
> > On Tue, Dec 10, 2013 at 10:30 PM, Eric Rescorla  wrote:
> >> After reviewing your request, the chairs believe that it does not raise
> any
> >> new substantive issues that were not known to the WG at the time of the
> >> decision to adopt ALPN and the subsequent WGLC. Therefore, we do not
> >> believe it is appropriate to re-open the issue at this time.
> >>
> >> Because the document has already passed WGLC, we will be asking the
> >> AD for advancement. You should of course feel free to reraise your
> objections
> >> during IETF LC.
> >
> > Thanks for the response Eric.
> >
> > I can understand that the chairs may not think it is appropriate to
> > re-open the issue at this time. It isn't surprising, because you have
> > lobbied for ALPN and against NPN, and you've also said that it is
> > important for Cisco (the other chair's employer) to have its
> > inspection appliances capable of learning which protocol is being used
> > on TLS connections.
> >
> > But, don't you think it would be better for the whole working group to
> > make that determination, instead of just the chairs? I think that if
> > you simply asked the working group if we (still) have have a
> > consensus, and the consensus is "go ahead with ALPN," then the whole
> > issue would be resolved within a week or two, and there would be no
> > trouble with IETF LC. But, if we don't verify that we actually have a
> > consensus now, then during IETF LC there will be doubt about whether
> > we still have a consensus.
> >
> > I remember somebody once saying that, when we have authority, it is
> > important to avoid not just impropriety, but also the *appearance* of
> > impropriety. We as a working group have the authority and
> > responsibility to everybody that uses IETF protocols and products
> > based on TLS to make sure we've made good decisions and achieved
> > consensus. So, I still think it is important, before advancing the
> > document to IETF LC, that we clarify and verify that we actually have
> > a consensus.
> >
> > Thanks again,
> > Brian
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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


(not taking any sides but stating how it looks like. I per=
sonally do not favor one over the other)

Hi Eric,


"if there were materially new information available to the=
 WG"



I think Brian made a good case that 'materially new inf=
ormation is available to the WG which became available after the WGLC'.=

(This is where the chairs disagrees with Brian and others on the l=
ist).




It appears you are pushing ahead with something that t=
he majority in the WG does not agree with _today_. (They might have agreed<=
br>with it when the WGLC happened but they no longer agree - because of new=
 information which became available).



Nobody is saying that ALPN should be shelved. What people like to see i=
s to have a vote at IETF89 I guess.

regards,

ralf





On Thu, Dec 12, 2013 at 2:58 AM, Eric Rescorla &=
lt;ekr@rtfm.com> wrote:


Brian,




You write:



=A0 But, don't you think it would be better for the whole working group=
 to

=A0 make that determination, instead of just the chairs? I think that if
=A0 you simply asked the working group if we (still) have have a

=A0 consensus, and the consensus is "go ahead with ALPN," then th=
e whole

=A0 issue would be resolved within a week or two, and there would be no

=A0 trouble with IETF LC.




This is the purpose served by the WGLC, which ended in September.

You are asking for yet another call for consensus; this would be appropriat=
e

if there were materially new information available to the WG which

became available after WGLC (otherwise, people could just keep

asking for consensus calls). =A0Whether this is in fact the case is a

question for the chairs and the ADs.



We consulted with the AD prior to taking this action, so perhaps he

will respond to you separately.



-Ekr






On Thu, Dec 12, 2013 at 8:58 AM, Brian Smith <brian@briansmith.org> wrote:

> On Tue, Dec 10, 2013 at 10:30 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>> After reviewing your request, the chairs believe that it does not =
raise any

>> new substantive issues that were not known to the WG at the time o=
f the

>> decision to adopt ALPN and the subsequent WGLC. Therefore, we do n=
ot

>> believe it is appropriate to re-open the issue at this time.

>>

>> Because the document has already passed WGLC, we will be asking th=
e

>> AD for advancement. You should of course feel free to reraise your=
 objections

>> during IETF LC.

>

> Thanks for the response Eric.

>

> I can understand that the chairs may not think it is appropriate to
> re-open the issue at this time. It isn't surprising, because you h=
ave

> lobbied for ALPN and against NPN, and you've also said that it is<=
br>
> important for Cisco (the other chair's employer) to have its

> inspection appliances capable of learning which protocol is being used=


> on TLS connections.

>

> But, don't you think it would be better for the whole working grou=
p to

> make that determination, instead of just the chairs? I think that if
> you simply asked the working group if we (still) have have a

> consensus, and the consensus is "go ahead with ALPN," then t=
he whole

> issue would be resolved within a week or two, and there would be no
> trouble with IETF LC. But, if we don't verify that we actually hav=
e a

> consensus now, then during IETF LC there will be doubt about whether
> we still have a consensus.

>

> I remember somebody once saying that, when we have authority, it is
> important to avoid not just impropriety, but also the *appearance* of<=
br>
> impropriety. We as a working group have the authority and

> responsibility to everybody that uses IETF protocols and products

> based on TLS to make sure we've made good decisions and achieved
> consensus. So, I still think it is important, before advancing the

> document to IETF LC, that we clarify and verify that we actually have<=
br>
> a consensus.

>

> Thanks again,

> Brian

_______________________________________________

TLS mailing list

TLS@ietf.org

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





--047d7bdc10eca8a6ea04ed565fa3--

From ynir@checkpoint.com  Thu Dec 12 06:42:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2321AE2ED for ; Thu, 12 Dec 2013 06:42:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 Y-cpx6_qZghq for ; Thu, 12 Dec 2013 06:42:32 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 82CF81AE2EB for ; Thu, 12 Dec 2013 06:42:31 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rBCEgOew019818; Thu, 12 Dec 2013 16:42:24 +0200
X-CheckPoint: {52A9C7B6-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.146]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 16:42:24 +0200
From: Yoav Nir 
To: Ralf Skyper Kaiser 
Thread-Topic: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
Thread-Index: AQHO9PKwvFEdHESyEEm0ZUd+bMkQKppOaaiAgAE1ZgCAACGegIAAsQoAgAATnQA=
Date: Thu, 12 Dec 2013 14:42:23 +0000
Message-ID: 
References:     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.54]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: multipart/alternative; boundary="_000_C634E116DF05432580DB0ECA5AFEC3FCcheckpointcom_"
MIME-Version: 1.0
Cc: "" 
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 14:42:35 -0000

--_000_C634E116DF05432580DB0ECA5AFEC3FCcheckpointcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Ralf

I don't think this is the majority of the WG. Those who argued for ALPN are=
 pretty much quiet now.

Also, votes or hums at IETF89 won't change anything, because the chairs can=
 only say at a meeting, "the sense of the room seems to be XXX, so we'll co=
nfirm this on the list". We're on the list now, so we might as well discuss=
 it now. No reason to delay this one by another three months.

I preferred ALPN for the following reasons:

  *   ALPN leaks very few bits of relevant information. For starters, it's =
HTTP/1 vs HTTP/2, which is not interesting at all, as they convey the same =
information. There are suggestions to place more things there, like various=
 mail protocols. Whether that happens or not, knowing that someone is readi=
ng mail rather than browsing the web is a small amount of information. This=
 should be balanced against:
  *   NPN is a huge change to the state machine. ALPN is simple and straigh=
tforward.

I don't think NPN would be a great disaster - I would implement whichever o=
ne is chosen, but I strongly prefer ALPN.

Yoav

On Dec 12, 2013, at 3:32 PM, Ralf Skyper Kaiser > wrote:

(not taking any sides but stating how it looks like. I personally do not fa=
vor one over the other)

Hi Eric,


"if there were materially new information available to the WG"

I think Brian made a good case that 'materially new information is availabl=
e to the WG which became available after the WGLC'.
(This is where the chairs disagrees with Brian and others on the list).

It appears you are pushing ahead with something that the majority in the WG=
 does not agree with _today_. (They might have agreed
with it when the WGLC happened but they no longer agree - because of new in=
formation which became available).

Nobody is saying that ALPN should be shelved. What people like to see is to=
 have a vote at IETF89 I guess.

regards,

ralf
[https://mail.google.com/mail/u/0/images/cleardot.gif]



On Thu, Dec 12, 2013 at 2:58 AM, Eric Rescorla > wrote:
Brian,

You write:

  But, don't you think it would be better for the whole working group to
  make that determination, instead of just the chairs? I think that if
  you simply asked the working group if we (still) have have a
  consensus, and the consensus is "go ahead with ALPN," then the whole
  issue would be resolved within a week or two, and there would be no
  trouble with IETF LC.

This is the purpose served by the WGLC, which ended in September.
You are asking for yet another call for consensus; this would be appropriat=
e
if there were materially new information available to the WG which
became available after WGLC (otherwise, people could just keep
asking for consensus calls).  Whether this is in fact the case is a
question for the chairs and the ADs.

We consulted with the AD prior to taking this action, so perhaps he
will respond to you separately.

-Ekr


On Thu, Dec 12, 2013 at 8:58 AM, Brian Smith > wrote:
> On Tue, Dec 10, 2013 at 10:30 PM, Eric Rescorla > wrote:
>> After reviewing your request, the chairs believe that it does not raise =
any
>> new substantive issues that were not known to the WG at the time of the
>> decision to adopt ALPN and the subsequent WGLC. Therefore, we do not
>> believe it is appropriate to re-open the issue at this time.
>>
>> Because the document has already passed WGLC, we will be asking the
>> AD for advancement. You should of course feel free to reraise your objec=
tions
>> during IETF LC.
>
> Thanks for the response Eric.
>
> I can understand that the chairs may not think it is appropriate to
> re-open the issue at this time. It isn't surprising, because you have
> lobbied for ALPN and against NPN, and you've also said that it is
> important for Cisco (the other chair's employer) to have its
> inspection appliances capable of learning which protocol is being used
> on TLS connections.
>
> But, don't you think it would be better for the whole working group to
> make that determination, instead of just the chairs? I think that if
> you simply asked the working group if we (still) have have a
> consensus, and the consensus is "go ahead with ALPN," then the whole
> issue would be resolved within a week or two, and there would be no
> trouble with IETF LC. But, if we don't verify that we actually have a
> consensus now, then during IETF LC there will be doubt about whether
> we still have a consensus.
>
> I remember somebody once saying that, when we have authority, it is
> important to avoid not just impropriety, but also the *appearance* of
> impropriety. We as a working group have the authority and
> responsibility to everybody that uses IETF protocols and products
> based on TLS to make sure we've made good decisions and achieved
> consensus. So, I still think it is important, before advancing the
> document to IETF LC, that we clarify and verify that we actually have
> a consensus.
>
> Thanks again,
> Brian
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



Email secured by Check Point

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


--_000_C634E116DF05432580DB0ECA5AFEC3FCcheckpointcom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable






Hi Ralf






I don't think this is the majority of the WG. Those who argued for ALP=
N are pretty much quiet now. 







Also, votes or hums at IETF89 won't change anything, because the chair=
s can only say at a meeting, "the sense of the room seems to be XXX, s=
o we'll confirm this on the list". We're on the list now, so we might =
as well discuss it now. No reason to delay
 this one by another three months.







I preferred ALPN for the following reasons:




    

  • ALPN leaks very few bits of relevant information. For starters, it's HT=
TP/1 vs HTTP/2, which is not interesting at all, as they convey the same in=
formation. There are suggestions to place more things there, like various m=
ail protocols. Whether that happens
 or not, knowing that someone is reading mail rather than browsing the web =
is a small amount of information. This should be balanced against:
  • =
NPN is a huge change to the state machine. ALPN is simple and straightforwa=
rd.







I don't think NPN would be a great disaster - I would implement whiche=
ver one is chosen, but I strongly prefer ALPN.







Yoav









On Dec 12, 2013, at 3:32 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote:






(not taking any sides but stating how it looks like. I per=
sonally do not favor one over the other)




Hi Eric,





"if there were materially new information available to the WG"






I think Brian made a good case that 'materially new information is availabl=
e to the WG which became available after the WGLC'.


(This is where the chairs disagrees with Brian and others on the list)=
.








It appears you are pushing ahead with something that the majority in the WG=
 does not agree with _today_. (They might have agreed

with it when the WGLC happened but they no longer agree - because of new in=
formation which became available).



Nobody is saying that ALPN should be shelved. What people like to see is to=
 have a vote at IETF89 I guess.



regards,



ralf



















On Thu, Dec 12, 2013 at 2:58 AM, Eric Rescorla <=
span dir=3D"ltr">
<ekr@rtfm.com><=
/span> wrote:



Brian,




You write:



  But, don't you think it would be better for the whole working group =
to

  make that determination, instead of just the chairs? I think that if=


  you simply asked the working group if we (still) have have a

  consensus, and the consensus is "go ahead with ALPN," then=
 the whole

  issue would be resolved within a week or two, and there would be no<=
br>
  trouble with IETF LC.





This is the purpose served by the WGLC, which ended in September.

You are asking for yet another call for consensus; this would be appropriat=
e

if there were materially new information available to the WG which

became available after WGLC (otherwise, people could just keep

asking for consensus calls).  Whether this is in fact the case is a
question for the chairs and the ADs.



We consulted with the AD prior to taking this action, so perhaps he

will respond to you separately.



-Ekr








On Thu, Dec 12, 2013 at 8:58 AM, Brian Smith <brian@briansmith.org> wrote:

> On Tue, Dec 10, 2013 at 10:30 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>> After reviewing your request, the chairs believe that it does not =
raise any

>> new substantive issues that were not known to the WG at the time o=
f the

>> decision to adopt ALPN and the subsequent WGLC. Therefore, we do n=
ot

>> believe it is appropriate to re-open the issue at this time.

>>

>> Because the document has already passed WGLC, we will be asking th=
e

>> AD for advancement. You should of course feel free to reraise your=
 objections

>> during IETF LC.

>

> Thanks for the response Eric.

>

> I can understand that the chairs may not think it is appropriate to
> re-open the issue at this time. It isn't surprising, because you have<=
br>
> lobbied for ALPN and against NPN, and you've also said that it is

> important for Cisco (the other chair's employer) to have its

> inspection appliances capable of learning which protocol is being used=


> on TLS connections.

>

> But, don't you think it would be better for the whole working group to=


> make that determination, instead of just the chairs? I think that if
> you simply asked the working group if we (still) have have a

> consensus, and the consensus is "go ahead with ALPN," then t=
he whole

> issue would be resolved within a week or two, and there would be no
> trouble with IETF LC. But, if we don't verify that we actually have a<=
br>
> consensus now, then during IETF LC there will be doubt about whether
> we still have a consensus.

>

> I remember somebody once saying that, when we have authority, it is
> important to avoid not just impropriety, but also the *appearance* of<=
br>
> impropriety. We as a working group have the authority and

> responsibility to everybody that uses IETF protocols and products

> based on TLS to make sure we've made good decisions and achieved

> consensus. So, I still think it is important, before advancing the

> document to IETF LC, that we clarify and verify that we actually have<=
br>
> a consensus.

>

> Thanks again,

> Brian

_______________________________________________

TLS mailing list

TLS@ietf.org

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

















Email secured by Check Point 



_______________________________________________

TLS mailing list

TLS@ietf.org

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












--_000_C634E116DF05432580DB0ECA5AFEC3FCcheckpointcom_--

From rsalz@akamai.com  Thu Dec 12 07:22:39 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6682A1A1F61 for ; Thu, 12 Dec 2013 07:22:39 -0800 (PST)
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, RP_MATCHES_RCVD=-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 kamckPv_1QZr for ; Thu, 12 Dec 2013 07:22:37 -0800 (PST)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id B7AF71ADF47 for ; Thu, 12 Dec 2013 07:22:37 -0800 (PST)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7C92548238; Thu, 12 Dec 2013 15:22:31 +0000 (GMT)
Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 6C8F94822A; Thu, 12 Dec 2013 15:22:31 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 518D347BD5; Thu, 12 Dec 2013 15:22:31 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.14]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Thu, 12 Dec 2013 10:22:30 -0500
From: "Salz, Rich" 
To: Marsh Ray , Watson Ladd , "Joseph Salowey (jsalowey)" 
Date: Thu, 12 Dec 2013 10:22:30 -0500
Thread-Topic: [TLS] TLS Charter Revision
Thread-Index: AQHO75QH12xj16hlv0SmAgrMfgWOIZpB1QcAgAF+I3CADT1cAA==
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>  <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com>
In-Reply-To: <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 15:22:39 -0000

I agree with Marsh that PFS should be included.

I am concerned about the 'political' emphasis on reducing round trips. One =
of the arguments heard I hear against 'https everywhere' is that the extra =
round-trips' cause too much latency and impact customer's web experience. I=
f we can work to reduce RTT without sacrificing security, then that's great=
 and I would like to see "while maintaining security features" or some such=
 added.

I would like to add a bullet that says backward compatibility with previous=
  versions is not a requirement. Given all that downgrade fallback issues t=
hat continually arise here, we should strongly consider if the right thing =
to do is just break the chain.

	/r$

-- =20
Principal Security Engineer
Akamai Technology
Cambridge, MA


From msweet@apple.com  Thu Dec 12 07:33:22 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CFE1AE32B for ; Thu, 12 Dec 2013 07:33:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 C7eKwJlIROY6 for ; Thu, 12 Dec 2013 07:33:18 -0800 (PST)
Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5561AE328 for ; Thu, 12 Dec 2013 07:33:18 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MXP00J7Q9VCTLY1@mail-out.apple.com> for tls@ietf.org; Thu, 12 Dec 2013 07:33:12 -0800 (PST)
X-AuditID: 11807165-b7f8e6d000004de8-cd-52a9d7381512
Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay7.apple.com (Apple SCV relay) with SMTP id 65.3A.19944.837D9A25; Thu, 12 Dec 2013 07:33:12 -0800 (PST)
Received: from [17.153.105.143] by chive.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MXP00HOU9VAWC00@chive.apple.com> for tls@ietf.org;  Thu, 12 Dec 2013 07:33:12 -0800 (PST)
From: Michael Sweet 
In-reply-to: <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com>
Date: Thu, 12 Dec 2013 10:33:10 -0500
Message-id: <3A9A4169-6B5E-453E-930A-F00291B541F4@apple.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>  <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com>
To: "Salz, Rich" 
X-Mailer: Apple Mail (2.1827)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDMr2txfWWQwcxr2hafzncxOjB6LFny kymAMYrLJiU1J7MstUjfLoEro+X2BZaC69wVsy5tY21gPMzZxcjJISFgInFhxxpGCFtM4sK9 9WxdjFwcQgLdTBIvPk1hh3D+MEocO3wCyOHgEBZQl/jaaQzSwCugJ7Fx3mxmEJtZQEti/c7j TCA2m4CaxO9JfawgNqdAmMT93YtZQFpZBFQl5vTYgoxkFpjPKNE4cQkTRK+2xJN3F1ghZtpI 3Dz6DWrvTCaJv9tfgSVEBJQljs98wAgySEJAVmL+6dIJjAKzkJwxC8kZs5CMXcDIvIpRoCg1 J7HSXC+xoCAnVS85P3cTIzjwClN3MDYutzrEKMDBqMTD++LgiiAh1sSy4srcQ4wSHMxKIrz3 tqwMEuJNSaysSi3Kjy8qzUktPsQozcGiJM57nxeoWiA9sSQ1OzW1ILUIJsvEwSnVwKhpVyN7 U0i5Sct1VoTdXNNspYpby0/ullCbFMt9epfb0u36bzNe+GzKej8l8ojdmY9zHgeduP7fy3jF 3iU7G67EeC92/KmbHP1z5jbrkG1NU1N59RU4vzF3/jPbeOKt+8qD9VMYnp4O3FR54Oya0wEC O1vv6cn+Tb4UsdzScLV18MYjuxROyrYpsRRnJBpqMRcVJwIA7O2GIzgCAAA=
Cc: "" 
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 15:33:22 -0000

FWIW, one of the big features of HTTP/2.0 is the ability to run multiple simultaneous requests over a single connection which mitigates most of the effects of extra RTT. What's left is the initial connection setup time - important for benchmarks, perhaps, but definitely down in the noise for most web pages...


On Dec 12, 2013, at 10:22 AM, Salz, Rich  wrote:

> I agree with Marsh that PFS should be included.
> 
> I am concerned about the 'political' emphasis on reducing round trips. One of the arguments heard I hear against 'https everywhere' is that the extra round-trips' cause too much latency and impact customer's web experience. If we can work to reduce RTT without sacrificing security, then that's great and I would like to see "while maintaining security features" or some such added.
> 
> I would like to add a bullet that says backward compatibility with previous  versions is not a requirement. Given all that downgrade fallback issues that continually arise here, we should strongly consider if the right thing to do is just break the chain.
> 
> 	/r$
> 
> --  
> Principal Security Engineer
> Akamai Technology
> Cambridge, MA
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


From patrick.ducksong@gmail.com  Thu Dec 12 07:59:50 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD92F1AE325 for ; Thu, 12 Dec 2013 07:59:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.256
X-Spam-Level: 
X-Spam-Status: No, score=-0.256 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, MISSING_HEADERS=1.021, 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 O7eeIpo593WD for ; Thu, 12 Dec 2013 07:59:48 -0800 (PST)
Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CEDAA1ADF64 for ; Thu, 12 Dec 2013 07:59:47 -0800 (PST)
Received: by mail-qc0-f173.google.com with SMTP id m20so460258qcx.32 for ; Thu, 12 Dec 2013 07:59:41 -0800 (PST)
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:cc:content-type; bh=KzjLZsHFa8AvASbXFAraEtleezM7hsez8eOgjcrOJbU=; b=iH5lGc7WFRqkCUw30J56CR1CZ2hDEVR2ytqgbLhJnIoTNPMhHS4SGhP14OuIOPqcv+ hXEi9fwAxvWGE98uqB26yZG8VOLMdy/kX2yYL3eN6ZzQCWcLPB8nUg6cxAp++WQU+1DY jUzUQHOH7mrSR6hljNhFEVlnbYeMW0pg4TRtGxnq3RHQb7vvAUcXX80q31RBl4AaS48j +Y6/28eKDSs7zkOQSlI0dn5EAMptesO1kYD8BT+D8nH9Eh2+4v99cQOPmiq1fFSqEvPK HzCXpxSzI8WRj21xUlGoqXWT0mnTwxtg3WiwilUliEj0UIytXMA4nAcjX/jxPpRcwHEG prYg==
MIME-Version: 1.0
X-Received: by 10.229.179.69 with SMTP id bp5mr7193665qcb.17.1386863981626; Thu, 12 Dec 2013 07:59:41 -0800 (PST)
Sender: patrick.ducksong@gmail.com
Received: by 10.140.86.168 with HTTP; Thu, 12 Dec 2013 07:59:41 -0800 (PST)
In-Reply-To: <3A9A4169-6B5E-453E-930A-F00291B541F4@apple.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>  <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com> <3A9A4169-6B5E-453E-930A-F00291B541F4@apple.com>
Date: Thu, 12 Dec 2013 10:59:41 -0500
X-Google-Sender-Auth: r-rvEPOIoIvpcIBdritiq04ug1Q
Message-ID: 
From: Patrick McManus 
Cc: "" 
Content-Type: multipart/alternative; boundary=001a11c2bf4efa24fa04ed586e7f
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 15:59:51 -0000

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

Time to first byte is extremely important to web content - so any kind of
latency-scaled overhead is viewed as a serious cost. TLS induced latency is
one factor that currently weighs against deploying content over https:// --
That is a dynamic most on this list would like to change I am sure.

Reducing setup overhead of all types is vitally important to that
constituency. That's not just assertion - we see that reflected (sometimes
indirectly) in ongoing efforts such as false start, snap start, stapling,
session tickets, iw 10, tcp fast open, http/2, tail loss probe, and quic.

A robust discussion can be had about cost-benefits of various approaches to
RTT elimination, but the demand side of the ledger should be clear.


On Thu, Dec 12, 2013 at 10:33 AM, Michael Sweet  wrote:

> FWIW, one of the big features of HTTP/2.0 is the ability to run multiple
> simultaneous requests over a single connection which mitigates most of the
> effects of extra RTT. What's left is the initial connection setup time -
> important for benchmarks, perhaps, but definitely down in the noise for
> most web pages...
>
>
> On Dec 12, 2013, at 10:22 AM, Salz, Rich  wrote:
>
> > I agree with Marsh that PFS should be included.
> >
> > I am concerned about the 'political' emphasis on reducing round trips.
> One of the arguments heard I hear against 'https everywhere' is that the
> extra round-trips' cause too much latency and impact customer's web
> experience. If we can work to reduce RTT without sacrificing security, then
> that's great and I would like to see "while maintaining security features"
> or some such added.
> >
> > I would like to add a bullet that says backward compatibility with
> previous  versions is not a requirement. Given all that downgrade fallback
> issues that continually arise here, we should strongly consider if the
> right thing to do is just break the chain.
> >
> >       /r$
> >
> > --
> > Principal Security Engineer
> > Akamai Technology
> > Cambridge, MA
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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


Time to first byte is extremely important to web cont=
ent - so any kind of latency-scaled overhead is viewed as a serious cost. T=
LS induced latency is one factor that currently weighs against deploying co=
ntent over https:// -- That is a dynamic most on this list would like to ch=
ange I am sure.



Reducing setup overhead of all types is vitally important to=
 that constituency. That's not just assertion - we see that reflected (=
sometimes indirectly) in ongoing efforts such as false start, snap start, s=
tapling, session tickets, iw 10, tcp fast open, http/2, tail loss probe, an=
d quic.



A robust discussion can be had about cost-benefits of variou=
s approaches to RTT elimination, but the demand side of the ledger should b=
e clear.



On Thu, Dec 12, 2013 at 10:33 AM, Michael Sweet <msweet@apple.com> wrote:

FWIW, one of the big features of HTTP/2.0 is the ability to run multiple si=
multaneous requests over a single connection which mitigates most of the ef=
fects of extra RTT. What's left is the initial connection setup time - =
important for benchmarks, perhaps, but definitely down in the noise for mos=
t web pages...







On Dec 12, 2013, at 10:22 AM, Salz, Rich <rsalz@akamai.com> wrote:



> I agree with Marsh that PFS should be included.

>

> I am concerned about the 'political' emphasis on reducing roun=
d trips. One of the arguments heard I hear against 'https everywhere=
9; is that the extra round-trips' cause too much latency and impact cus=
tomer's web experience. If we can work to reduce RTT without sacrificin=
g security, then that's great and I would like to see "while maint=
aining security features" or some such added.


>

> I would like to add a bullet that says backward compatibility with pre=
vious =A0versions is not a requirement. Given all that downgrade fallback i=
ssues that continually arise here, we should strongly consider if the right=
 thing to do is just break the chain.


>

> =A0 =A0 =A0 /r$

>

> --

> Principal Security Engineer

> Akamai Technology

> Cambridge, MA

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

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




_______________________________________________________________=


Michael Sweet, Senior Printing System Engineer, PWG Chair




_______________________________________________

TLS mailing list

TLS@ietf.org

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





--001a11c2bf4efa24fa04ed586e7f--

From nmav@redhat.com  Thu Dec 12 08:08:59 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAAB1AE345 for ; Thu, 12 Dec 2013 08:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 bVJpcdVc9YpP for ; Thu, 12 Dec 2013 08:08:58 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id E00391AE342 for ; Thu, 12 Dec 2013 08:08:57 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBCG8hru005123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Dec 2013 11:08:43 -0500
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBCG8fhU026966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Dec 2013 11:08:42 -0500
Message-ID: <1386864521.31585.57.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Yoav Nir 
Date: Thu, 12 Dec 2013 17:08:41 +0100
In-Reply-To: 
References:      
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.23
Cc: "" 
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 16:09:00 -0000

On Thu, 2013-12-12 at 14:42 +0000, Yoav Nir wrote:

> I preferred ALPN for the following reasons:
>       * ALPN leaks very few bits of relevant information. For
>         starters, it's HTTP/1 vs HTTP/2, which is not interesting at
>         all, as they convey the same information. There are
>         suggestions to place more things there, like various mail
>         protocols. Whether that happens or not, knowing that someone
>         is reading mail rather than browsing the web is a small amount
>         of information. This should be balanced against:

I also prefer ALPN, for the additional reasons, that (1) uses the
standard TLS extension mechanism, and (2) a load balancer, or
super-server can distribute the protocols indicated in ALPN to various
(different) servers. That cannot be done in any efficient way using
NPN. 

While I believe privacy concerns are important, in that case nothing is
revealed to an adversary that was not available before (i.e., the
service was always known due to TCP port number). Moreover applications
that require privacy can always use steganography and advertise a phony
protocol.

TLS has specific design goals, and hiding the service and the connecting
peers were never among them (don't say I agree with that). Adding both
is a major redesign, which I agree with the calls to be postponed to TLS
1.3 (or 2.0). Otherwise if every extension designs its privacy goals
differently, we get a protocol full of hacks that doesn't allow to be
improved in a sensible way.

regards,
Nikos



From msweet@apple.com  Thu Dec 12 09:18:08 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9531AE0BE for ; Thu, 12 Dec 2013 09:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level: 
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 m6oml7C3EmLN for ; Thu, 12 Dec 2013 09:18:05 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 631181AE059 for ; Thu, 12 Dec 2013 09:18:05 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_V6jKwnWlPpMEqAMOrOoHhQ)"
Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MXP002UHEPWGDP1@mail-out.apple.com> for tls@ietf.org; Thu, 12 Dec 2013 09:17:59 -0800 (PST)
X-AuditID: 11807153-b7f396d00000722b-89-52a9efc4d483
Received: from [17.153.37.225] (Unknown_Domain [17.153.37.225]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate)	by relay3.apple.com (Apple SCV relay) with SMTP id F0.23.29227.6CFE9A25; Thu, 12 Dec 2013 09:17:59 -0800 (PST)
From: Michael Sweet 
In-reply-to: 
Date: Thu, 12 Dec 2013 12:17:58 -0500
Message-id: <4650BF20-FD1B-446D-97C7-BB4A33FCE258@apple.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>  <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com> <3A9A4169-6B5E-453E-930A-F00291B541F4@apple.com> 
To: Patrick McManus 
X-Mailer: Apple Mail (2.1812)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUiOFP1oe7x9yuDDDoP81sc+RZrsX/PX3aL T+e7GB2YPbae/MHmsWTJTyaPvgNdrAHMUVw2Kak5mWWpRfp2CVwZr162MRec8K/omDubuYFx o3MXIyeHhICJxIWOeYwQtpjEhXvr2boYuTiEBHqZJJZfnQOU4OAQFlCX+NppDFLDK6AnceXx dhaQMLNAgsST5WEgYTYBNYnfk/pYQcKcAoESO+dpgoRZBFQlfv1sZgaxmQWUJWZ1LWeFmGIj 8WR/KzuILSTQySxx/o8kiC0ioCVxdOlEdpAxEgKyEp8Om01g5JuFZO8shL2zwIZqSyxb+JoZ wtaTeNn0jh1TXFfi4rpJjAsY2VYxChSl5iRWGuslFhTkpOol5+duYgQFa0Nh8A7GP8usDjEK cDAq8fC+OLgiSIg1say4MvcQowQHs5II7+vHK4OEeFMSK6tSi/Lji0pzUosPMUpzsCiJ897l BaoWSE8sSc1OTS1ILYLJMnFwSjUwWuSeWGF7L2hx78UN6ucvfarYvXqv00Q20+Bv03/VTDvx IlTb8nvdqVu7TzjIP/Q2eFHOwxn35YHLh2feS72Va+Z+YypNWhsh+Dm8Uel6zKRnE969/Lv+ /JK0n7e+TJyReGzuwjNSyStNGU5FpzZN0D67kOWh1MmbXWuXb33VZj+7yO7rJz2VIAklluKM REMt5qLiRABt9Qo5UgIAAA==
Cc: "" 
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 17:18:08 -0000

--Boundary_(ID_V6jKwnWlPpMEqAMOrOoHhQ)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

Patrick,

While I agree that minimizing RTT is a laudable goal, I don't think it is a necessary goal for TLS/1.3.

Witness that browsers/servers that support Google's TLS-encrypted SPDY have already seen significant performance improvement without needing a 0 RTT version of TLS.  And as HTTP/2.0 shares some of the same design elements, we can expect to see similar improvements over TLS-encrypted HTTP/1.1 as well.

Minimizing RTT helps with initial response latency only.  And I would argue the primary factor against using TLS for everything is performance and resource usage and NOT latency.  If you can, by using SPDY or HTTP/2.0, reduce the number of connections a web browser makes to your server(s) by an order of magnitude, that will be a far greater factor in the decision making process than shaving maybe 250ms from the initial connection latency of each connection.


On Dec 12, 2013, at 10:59 AM, Patrick McManus  wrote:

> Time to first byte is extremely important to web content - so any kind of latency-scaled overhead is viewed as a serious cost. TLS induced latency is one factor that currently weighs against deploying content over https:// -- That is a dynamic most on this list would like to change I am sure.
> 
> Reducing setup overhead of all types is vitally important to that constituency. That's not just assertion - we see that reflected (sometimes indirectly) in ongoing efforts such as false start, snap start, stapling, session tickets, iw 10, tcp fast open, http/2, tail loss probe, and quic.
> 
> A robust discussion can be had about cost-benefits of various approaches to RTT elimination, but the demand side of the ledger should be clear.
> 
> 
> On Thu, Dec 12, 2013 at 10:33 AM, Michael Sweet  wrote:
> FWIW, one of the big features of HTTP/2.0 is the ability to run multiple simultaneous requests over a single connection which mitigates most of the effects of extra RTT. What's left is the initial connection setup time - important for benchmarks, perhaps, but definitely down in the noise for most web pages...
> 
> 
> On Dec 12, 2013, at 10:22 AM, Salz, Rich  wrote:
> 
> > I agree with Marsh that PFS should be included.
> >
> > I am concerned about the 'political' emphasis on reducing round trips. One of the arguments heard I hear against 'https everywhere' is that the extra round-trips' cause too much latency and impact customer's web experience. If we can work to reduce RTT without sacrificing security, then that's great and I would like to see "while maintaining security features" or some such added.
> >
> > I would like to add a bullet that says backward compatibility with previous  versions is not a requirement. Given all that downgrade fallback issues that continually arise here, we should strongly consider if the right thing to do is just break the chain.
> >
> >       /r$
> >
> > --
> > Principal Security Engineer
> > Akamai Technology
> > Cambridge, MA
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> _______________________________________________
> 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

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--Boundary_(ID_V6jKwnWlPpMEqAMOrOoHhQ)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable

Patrick,

While I agree that =
minimizing RTT is a laudable goal, I don't think it is a necessary goal =
for TLS/1.3.

Witness that browsers/servers that =
support Google's TLS-encrypted SPDY have already seen significant =
performance improvement without needing a 0 RTT version of TLS. =
 And as HTTP/2.0 shares some of the same design elements, we can =
expect to see similar improvements over TLS-encrypted HTTP/1.1 as =
well.

Minimizing RTT helps with initial =
response latency only.  And I would argue the primary factor =
against using TLS for everything is performance and resource usage and =
NOT latency.  If you can, by using SPDY or HTTP/2.0, reduce the =
number of connections a web browser makes to your server(s) by an order =
of magnitude, that will be a far greater factor in the decision making =
process than shaving maybe 250ms from the initial connection latency of =
each connection.


On Dec 12, 2013, =
at 10:59 AM, Patrick McManus <pmcmanus@mozilla.com> =
wrote:

Time to first byte is extremely =
important to web content - so any kind of latency-scaled overhead is =
viewed as a serious cost. TLS induced latency is one factor that =
currently weighs against deploying content over https:// -- That is a =
dynamic most on this list would like to change I am sure.



Reducing setup overhead of all types is vitally important =
to that constituency. That's not just assertion - we see that reflected =
(sometimes indirectly) in ongoing efforts such as false start, snap =
start, stapling, session tickets, iw 10, tcp fast open, http/2, tail =
loss probe, and quic.



A robust discussion can be had about cost-benefits of =
various approaches to RTT elimination, but the demand side of the ledger =
should be clear.



On Thu, Dec 12, 2013 at 10:33 AM, Michael Sweet <msweet@apple.com> wrote:

FWIW, one of the big features of HTTP/2.0 is the ability to run multiple =
simultaneous requests over a single connection which mitigates most of =
the effects of extra RTT. What's left is the initial connection setup =
time - important for benchmarks, perhaps, but definitely down in the =
noise for most web pages...







On Dec 12, 2013, at 10:22 AM, Salz, Rich <rsalz@akamai.com> wrote:



> I agree with Marsh that PFS should be included.

>

> I am concerned about the 'political' emphasis on reducing round =
trips. One of the arguments heard I hear against 'https everywhere' is =
that the extra round-trips' cause too much latency and impact customer's =
web experience. If we can work to reduce RTT without sacrificing =
security, then that's great and I would like to see "while maintaining =
security features" or some such added.


>

> I would like to add a bullet that says backward compatibility with =
previous  versions is not a requirement. Given all that downgrade =
fallback issues that continually arise here, we should strongly consider =
if the right thing to do is just break the chain.


>

>       /r$

>

> --

> Principal Security Engineer

> Akamai Technology

> Cambridge, MA

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

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



=

______________________________________________________________=
_

Michael Sweet, Senior Printing System Engineer, PWG Chair




_______________________________________________

TLS mailing list

TLS@ietf.org

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




_______________________________________________
TLS mailing =
list
TLS@ietf.org
https://www.ietf.org/mail=
man/listinfo/tls



_________________________________________________________
Michael =
Sweet, Senior Printing System Engineer, PWG =
Chair




=

--Boundary_(ID_V6jKwnWlPpMEqAMOrOoHhQ)--

From internet-drafts@ietf.org  Thu Dec 12 11:25:33 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A131AE404; Thu, 12 Dec 2013 11:25:33 -0800 (PST)
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 k14hRETpBGL8; Thu, 12 Dec 2013 11:25:31 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 272A11AE138; Thu, 12 Dec 2013 11:25:31 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131212192530.4014.57676.idtracker@ietfa.amsl.com>
Date: Thu, 12 Dec 2013 11:25:30 -0800
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-pwd-03.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: Thu, 12 Dec 2013 19:25:33 -0000

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

	Title           : Secure Password Ciphersuites for Transport Layer Securit=
y (TLS)
	Author(s)       : Dan Harkins
                          Dave Halasz
	Filename        : draft-ietf-tls-pwd-03.txt
	Pages           : 33
	Date            : 2013-12-12

Abstract:
   This memo defines several new ciphersuites for the Transport Layer
   Security (TLS) protocol to support certificate-less, secure
   authentication using only a simple, low-entropy, password.  The
   ciphersuites are all based on an authentication and key exchange
   protocol that is resistant to off-line dictionary attack.


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

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

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


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 dharkins@lounge.org  Thu Dec 12 11:39:43 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B897C1AE429 for ; Thu, 12 Dec 2013 11:39:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.467
X-Spam-Level: 
X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 hCMc8nc-9Dba for ; Thu, 12 Dec 2013 11:39:41 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 190811AE427 for ; Thu, 12 Dec 2013 11:39:41 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4BDD910224008 for ; Thu, 12 Dec 2013 11:39:35 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 12 Dec 2013 11:39:35 -0800 (PST)
Message-ID: <6533edf7da9256371b12b19662afa1cf.squirrel@www.trepanning.net>
Date: Thu, 12 Dec 2013 11:39:35 -0800 (PST)
From: "Dan Harkins" 
To: tls@ietf.org
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Subject: [TLS] new version of draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 19:39:43 -0000

  Hello,

  I just uploaded draft-iet-tls-pwd-03 that incorporates resolution
to comments received from WGLC. These include:

  - test vectors of an example exchange (added to -02).
  - address the issue Bodo Moeller described that allowed a server
     to impose a weak group on the client.
  - inclusion of a technique to protect the username based on
     a comment by Trevor Perrin.

The scheme for username protection has a number of benefits:

   - it does not increase the number of messages
   - it does not require storage of any server secrets on clients
   - is resistant to passive monitoring attack and active attack
      by a malicious server (no I will not be providing a security
      proof to back up those claims)
   - protected username will be different with each run of the
      protocol
   - minimal overhead-- 32+16 = 48 bytes leaving enough
      for insanely long usernames

and the drawbacks are that it opens up a potential for DoS
attacks and it also does not have any forward secrecy-- server
compromise can result in the disclosure of the names of clients
from previous runs of the protocol.

  regards,

  Dan.




From akr@akr.io  Thu Dec 12 12:55:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D4B1AE4C5 for ; Thu, 12 Dec 2013 12:55:35 -0800 (PST)
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 GYOca9UYOTfh for ; Thu, 12 Dec 2013 12:55:31 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9174E1AE4AE for ; Thu, 12 Dec 2013 12:55:31 -0800 (PST)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id 3CE7D60443 for ; Thu, 12 Dec 2013 20:55:24 +0000 (GMT)
Message-ID: <52AA22C4.3000500@akr.io>
Date: Thu, 12 Dec 2013 20:55:32 +0000
From: Alyssa Rowan 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tls@ietf.org
References:       <1386864521.31585.57.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1386864521.31585.57.camel@dhcp-2-127.brq.redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 20:55:35 -0000

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

Hi. Watching this list since IETF 88, I note with some interest Eric's
and Sean's responses to Brian's email raising profound concerns about
the consensus call on ALPN and asking for a reconsideration and new
consensus call.

With the greatest of respect, saying no new 'substantive' or
'material' information which might warrant a re-examination of this
issue has come to light since early September - in the light of the
Snowden revelations and the IETF 88 "Hardening The Internet" Technical
Plenary and its landmark discussions, mind you - is quite plainly wrong.

It could not be more significant to the internet in general, and this
working group in particular. We know Nation State Adversaries
[hereinafter NSA] are actively attacking the internet via
surveillance; we know that they laugh in the face of existing TLS
deployments; and we know they have backdoored and stymied multiple
encryption products and standards before.

I'm certain neither the chairs nor ADs would wish for their integrity
and motivations to be questioned - but one could be forgiven for
perceiving their responses as blatant railroading. We already know the
NSA have previously manipulated cryptographic standards to weaken them
to their advantage, and it worries me that any such manipulation (were
it to occur) would look exactly like this, and that the chair and ADs
would be obvious targets. That troubles me. It should trouble you, too.

It was clear from IETF 88 that the advantage of the open process in
developing cryptographic standards is trust. We should never squander
that trust by acting rashly and standardising a metadata extension to
the most widely-used cryptographic protocol without properly
addressing the very real concerns raised - and, where necessary,
stopping, rewinding, pausing, and reconsidering to make sure that
whatever we decide, we do so as carefully and knowledgeably as possible.

With that in mind, I note the comments of others, and shall add my
own. I'll try to keep my thoughts to bullets here.

The core issue:
• Using ALPN clearly identifies encapsulated protocol metadata to Eve.
• Using NPN does not.
  - The most widespread NSA attacks, by far, are passive eavesdropping.
  - Metadata = surveillance¹.
    · Even small amounts of metadata can be surprisingly dangerous.
    · Especially in aggregate.
  - How much of a vulnerability is knowing what protocol is inside TLS?
    · Passive target fingerprinting
    · Known-plaintext = potential trouble spot for wobbly stream cipher?
  - Where practical, we should design protocols to protect metadata².
  - Any protocol might use it, NOT just HTTP/1 vs. HTTP/2:
    · Example: WebSockets, already live in-the-wild [NPN, often w/SPDY].
    · Many, many other protocols use TLS to protect them too.
    · Some other protocols also use TCP/443; firewalls tend to allow it.
    · ALPN/NPN are both apt solutions for them to identify their nature.
    · If you want to keep it just to HTTP/1 or HTTP/2, say so with MUST.
      * And then don't we only need one bit? ;)

• Where might ALPN be better than NPN?
  - Deployment:
    · Simple. Hard to overcomplicate TLS 1.2 extension with plaintext.
  - To TLS endpoint server:
    · Maybe faster? How much faster?
  - To an untrusted third party:
    · Protocol filtering firewall. (notably, a Great Firewall)
    · NSA, running Blue Coat, Narus or X-KEYSCORE en masse.
    · Simplifies stream reconstruction, especially with multiplexing
      * Much worse for Tor. Tor would have to lie about ALPN.
  - To a trusted third party that doesn't speak TLS e.g. load balancer:
    · Identify encapsulated protocol, plaintext, without speaking TLS.
    · When is that useful? Multiplexed TCP/443 encapsulating protocol?
      * But why TCP/443? Because of protocol filtering firewalls.
        + They stop stuff working.
        + Arguably this is what firewalls are supposed to do.
        + As above: Not all firewalls are authorised/desirable.
        + Compare interaction of IPv4 exhaustion/NAT/inbound.
      * But ALPN lets protocol filtering firewalls see inside!
        + Benefit of TCP/443 muxing removed by ALPN firewall support.
        + Those with something to hide must lie about ALPN if mandatory.
      * So we might as well just use another TCP port. Or another DNS.
        + Interactions with SNI. Future TLS 1.3 SNI encryption?
        + Interactions with DNS/DNSSEC/DNScurve or something else?
      * Am I missing something here? WebSockets?
      * In big load-balancer, would TLS endpoint do better? Don't know.

• Where might NPN be better than ALPN?
  - Deployment:
    · Negative: Significantly more complex than ALPN.
    · But widely deployed already, thanks to SPDY drafts and WebSockets.
    · Patches already available for numerous TLS libraries.
  - To TLS endpoint server:
    · Maybe slightly slower? How much slower?
  - To an untrusted third party:
    · Both firewall and NSA have to guess protocol via traffic analysis
    · Complicates stream reconstruction, especially with multiplexing
      * Tor would be able to actually use NPN, potentially?
  - To a trusted third party that doesn't speak TLS e.g. load balancer:
    · Can't identify encapsulated protocol without speaking TLS/keys.
    · When is that useful? Scenarios which ALPN disallows if supported.

• Whatever picked, we're stuck with it, if TLS 1.2 still supported.
  - The HTTP/2 effect. Huge.
  - Need to consider in light of TLS 1.3 as well.
    · Hard to deprecate ALPN if firewalls filter lack-of-ALPN.
  - But TLS 1.3 wants to encrypt as much of the handshake as possible³.
    · This goal is in direct conflict with more plaintext metadata.
    · Suggestive that TLS 1.3 perhaps MUST NOT support ALPN?
    · So why add it now, to have a really hard time binning it later?
  - Bigger handshake for implementing both. Pick one good one.

• Proposal to implement ALPN & just lie as standard practice:
  - I think that proposal is silly.
  - We'd need to implement NPN as well, later.
  - Wouldn't we be better off just implementing NPN instead?

I personally lean strongly towards NPN myself, for the above reasons.

Others will no doubt have comments on my reasons, or have different
reasons, and may or may not come to the same decision.

Most importantly, whatever is ultimately chosen, I want it to be
chosen openly, transparently, and with reasons like the above, and
everything new that has come to light since the initial consensus
call, properly and publicly considered. Thank you.

___
1. A snappy comment courtesy of [Schenier]
;
also, comments at IETF 88 Technical Plenary.
2. [Perpass] IETF 88 T/P Hum; resulting proposed BCP

3. Proposed updated TLS WG charter drafts; IETF 88 discussions.

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

iQIcBAEBCgAGBQJSqiLDAAoJEOyEjtkWi2t6LQwP/RFF3it6pzgLh4Xcf53MjqLI
PZpKSOmzEiwcQgFDWuMKoorvW10bjZ0PWaRXx5Xvi5eMQ9gQZLFL8y18I4Ps03C6
vruBL/7Sv/ZZ3CSUY+qGHkpExQdAoPjlcokur8zV0LvqJIof2RuSqTmHq7hz2ITm
sKtWVl87ZJYDSOeFnsx8Aijse3Bc8Ow4v6ib8qpwxE5NgAamSiV3hPxiyXqxzRa7
BAhSuIviX3WDjWTvj5l6USMQaVQBDO5VXaT+4opUr+uZysuFMJNoOcu8asnD5IgB
4tKus3U2ZDgOpTf6BK1rcjfxnIsPBc9Er9mqYmAPi9Vm7zXPVz/wwjfVsZ5uRUoY
qyyIJS/OjNkQVbykZsuwRHpV6ZJ6AzaItrHeXGMluTrs/zvYughjA4aw0jfNDeO/
wlg70nomu9cxSDjPIshInYpkBGM1UKlpLMfMvO5ml7ERATZTUTXHkNhbbErcyfNq
7U3MENqDKG0jERjwt3dvM1g6+SZWu1UuSelZMwZd6jh84mmn1fJ9A0tnLGDxJQ64
QGHKO/g55GRL6q6T+dVTGibuqrwaKpaL4R3zuWeBB80d2URIEMQXxTxlqpVSYCr1
khd5m+WHOMPgRMuITW4dWxvSXgIAGkyMxWOtb711dPL8BEBNqvGVTQPNIPsPuuI4
0fIhJBRhRyHXvuJp6fj/
=cTIx
-----END PGP SIGNATURE-----

From sfriedl@cisco.com  Thu Dec 12 13:22:23 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707811AE4E0 for ; Thu, 12 Dec 2013 13:22:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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.001, 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 gxIRN16eaXND for ; Thu, 12 Dec 2013 13:22:19 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 36B3A1AE4DE for ; Thu, 12 Dec 2013 13:22:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11795; q=dns/txt; s=iport; t=1386883333; x=1388092933; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lQRmzBs9Rp6NuTp0CNpwL2CDj3YCERu3RZSJK0OWX8E=; b=JQECJSTU1QEdFr361dqtz37kYXvp2rDan9KGUk7LbZjVGqy5Ix1CLzhu MHMnX8TubbGjRIlgaKezLCg/YV0m7dRDTmH4Mepc7vzm6e1ZUl/RWvC/s H/MHKjZlsciBrXpq+cN7Sq7wjkbX1z4528bM1ZNykEunuXwR2ouPPlg/I s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAHQoqlKtJV2Y/2dsb2JhbABZgwo4VbhYgR0WdIIlAQEBBAEBATcyAQELDAQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIFodmDcMhF44yCgcBHzEHBoMcgRMEmUWQZIMpgWgJFyI
X-IronPort-AV: E=Sophos;i="4.95,473,1384300800"; d="scan'208";a="291219507"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 12 Dec 2013 21:22:10 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBCLMABe002221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 21:22:10 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 15:22:09 -0600
From: "Stephan Friedl (sfriedl)" 
To: Brian Smith 
Thread-Topic: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
Thread-Index: AQHO9PKK34gM8jd2uUavYB7+hYI2r5pOTI8AgAAZ0wCAABfOAIABARcAgACh/QCAAN8DIA==
Date: Thu, 12 Dec 2013 21:22:09 +0000
Message-ID: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C2322006C@xmb-aln-x02.cisco.com>
References:  <52A77DB4.7020501@gmx.net> <52A7935E.5020906@cs.tcd.ie> <87ob4o1dbd.fsf@alice.fifthhorseman.net> <52A87F00.7000304@cs.tcd.ie> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.94.178.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF TLS Working Group 
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 21:22:23 -0000

Brian,

By intent, ALPN was drafted to be a standard, run-of-the-mill TLS Extension=
 with no changes to the fundamental extension model or state machine of TLS=
 implementations.  So yes, it is not HTTP-specific, no disagreement there. =
 The original ask from the HTTP/bis working group was for a facility to ind=
icate protocol choice between HTTP/1 and HTTP/2, but both ALPN and NPN are =
not limited to HTTP protocols only.

We anticipated the provisioning of multiple services on a single port on a =
single host as you describe and under those circumstances ALPN provides wha=
t I feel could be a couple of security and server management features over =
NPN.  First, ALPN does not require the server to disclose all the protocols=
 it supports which is what NPN requires.  With ALPN an attacker could make =
repeated client requests to the host probing for different protocols but AL=
PN makes it harder for an attacker to determine the complete list of protoc=
ols exposed on a single host/port combination.  Secondly, with NPN the serv=
er side cert has been chosen before the protocol has been determined which =
would pretty much require all the services exposed on a single host/port co=
mbination with NPN to use the same cert.  With ALPN, as with SNI, the proto=
col is determined prior to certificate selection so administrators could co=
ntinue to use different certs for different services/protocols if they so d=
esire.

Given that the server publishes its list of supported protocols in the clea=
r in NPN, I'd suggest that even a passive attacker could figure out the pro=
tocol in use with little difficulty.  Traffic analysis is one approach but =
if an attacker knew which user agent the client was using to connect to the=
 service, then the chosen protocol would be obvious from the user agent imp=
lementation.  It strikes me that protocols which use the STARTTLS mechanism=
 to upgrade to a secured channel would probably require some modification o=
n both client and server to initiate the connection in TLS with NPN or ALPN=
 and the appropriate protocol identifier rather than starting in plaintext.

Finally, I don't believe that the TLS 1.3 effort is going to 'waste time fi=
guring out how to encrypt ALPN', rather it appears to me as if TLS 1.3 is f=
ocusing on early encryption in the handshake which would cover ALPN, SNI an=
d any other extension in use now or in the future. =20

Thanks,

Stephan


> -----Original Message-----
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Brian Smith
> Sent: Wednesday, December 11, 2013 5:44 PM
> To: Stephen Farrell
> Cc: IETF TLS Working Group
> Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns=
)
>=20
> On Wed, Dec 11, 2013 at 7:04 AM, Stephen Farrell
>  wrote:
> > On 12/10/2013 11:44 PM, Daniel Kahn Gillmor wrote:
> >> On Tue 2013-12-10 17:19:10 -0500, Stephen Farrell wrote:
> >>> FWIW, I agree with you in general, but in this case the privacy leak
> >>> is non-existent if its only HTTP/1.1 vs HTTP/2.0 - since the binary
> >>> encoding and lack of head-of-line blocking in the latter will give
> >>> that game away anyway.
> >>
> >> i don't think i understand this argument.  are you saying that
> >> traffic analysis will disclose what protocol is in use in this case?
> >
> > I believe so, esp since there's just http/1.1 and http/2.0 in question
> > (well, maybe spdy too for some time).
>=20
> Hi Stephen,
>=20
> You made this argument in two different threads, and I'll just reply in t=
his
> one.
>=20
> I am not concerned about a MitM learning whether you are talking
> HTTP/1 vs HTTP/2 vs. SPDY. If ALPN were only capable of disclosing which
> version of HTTP you are speaking, I'd not be objecting so strongly to it.
>=20
> However, the ALPN draft [0] isn't HTTP-specific. It happens to be the cas=
e
> that only HTTP-related protocol identifiers are currently planned to be
> registered, but that doesn't mean that HTTP is the only use case for prot=
ocol
> negotiation.
>=20
> One of my goals is to make it possible for an email server to multiplex H=
TTP,
> SMTP, LDAP, IMAP, and/or POP all over port 443 on the same host (with one
> hostname). So, for example, when a MitM sees a connection to
> example.org:443, the MitM doesn't know which of those protocols are being
> used, without doing traffic analysis. Then, the next step is to add featu=
res to
> TLS to make traffic analysis much more expensive and/or potentially
> impossible. I have talked to one large email provider already about doing=
 the
> first part (multiplexing all email protocols over 443), and I got a prett=
y positive
> response. I don't know if they would be willing to do the second part to =
make
> traffic analysis difficult. But, I think email providers of the Lavabit-l=
ike
> predisposition *would* be likely to consider adopting anti-traffic-analys=
is
> features, because those features are likely to be somewhat expensive in
> terms of bandwidth used.
>=20
> I think doing more to prevent traffic analysis in the messaging space
> (including, but not limited to, email) is a very important part of the pe=
rpass
> effort. Without it, we help enable attackers with global resources to inf=
er
> social networks through traffic analysis, even when the traffic is encryp=
ted.
> By making it difficult for an adversary to determine when you are sending=
 a
> message, and when you are receiving a message, we make their inference
> much harder and hopefully impractical.
>=20
> Again, if the ALPN extension in the ClientHello was empty and meant "I
> prefer HTTP/2 if you support HTTP" then I wouldn't have any objection.
> However, currently the ALPN extension effectively allows arbitrary
> application data to be sent in the clear, even though it is intended to o=
nly
> allow protocol negotiation. We've already seen how, in the case of http2-=
tls-
> relaxed, it is tempting to extend ALPN in ways we're not intended it to b=
e
> used, with negative results. I object to that, because it isn't safe.
>=20
> I also support NPN is because it has a much higher safety margin.
> Again, you can see the additional safety margin that NPN has over ALPN by
> looking at the analysis of the http2-tls-relaxed I did. Although we seem =
to all
> agree that negotiating http2-tls-relaxed is an unsound idea in general, t=
he
> point still stands that encrypting the information in the handshake provi=
ded
> defense-in-depth against a serious issue.
>=20
> > If hiding that
> > somewhat is the claimed benefit and if that diverted scarce WG
> > resources away from tls1.3 then I figure doing the work in tls1.3 is
> > better.
>=20
> Actually, standardizing NPN would speed up the adoption of TLS 1.3, becau=
se
> we wouldn't waste time trying to encrypt ALPN. We may want to change
> how NPN works in TLS 1.3, and I am all for that. However, after thinking
> about all the possibilities I could come up with, ultimately if we're goi=
ng to
> encrypt the protocol negotiation information in TLS 1.3, the negotiation =
will
> have to work more like NPN (server offers protocols, client chooses one)
> than ALPN (client offers protocols, server chooses one). So, adopting ALP=
N
> now, and then trying to fix ALPN in TLS 1.3, would mean that browsers wou=
ld
> go from NPN to ALPN back to something very much like NPN. So, if anything
> is slowing down work on TLS, it is actually ALPN itself.
>=20
> > I really like the idea of meeting that requirement. But again it seems
> > to me like it'd be better baked into tls1.3 and not done as an
> > extension to tls1.2 or earlier.
>=20
> I think it is likely that all of "TLS 1.3" will be effectively a set of e=
xtensions to
> TLS 1.2 and earlier anyway. One reason is that we've already seen evidenc=
e
> of widespread intolerance to version 0x0304 in the ClientHello: 10% of ho=
sts
> surveyed, according to [1]. The second reason is that it is easier to pro=
totype
> new features as extensions than trying to implement everything all at onc=
e.
> The third reason is that some people already have plans to backport at le=
ast
> some "TLS 1.3" features to earlier versions.
>=20
> > My reasoning there
> > assumes that we figure tls1.3 will be widely deployed more quickly
> > than previous updates due to the collective win of running http/2.0
> > over tls1.3. Doing a lot of things in both
> > tls1.3 and as extensions to earlier versions also seems less likely to
> > work out, given that we all have limited cycles.
> >
> > But yes, that's prediction with which one could disagree.
>=20
> I think your prediction is accurate, in that TLS 1.3 deployment will be m=
uch
> faster than TLS 1.2 deployment. However, I doubt TLS 1.3 deployment will =
be
> widespread enough any time in the next 5-10 years for browsers to be will=
ing
> to degrade performance or security when falling back to TLS 1.2 and earli=
er.
> That means we should plan on 10+ years of unencrypted ALPN in the
> ClientHello from all major browsers, if we standardize unencrypted ALPN
> now.
>=20
> [0] tools.ietf.org/html/draft-friedl-tls-applayerprotoneg-02
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=3D733647#c48
>=20
> Cheers,
> Brian
>=20
> >> And protocol negotiation is not only useful in the
> >> HTTP/1.1?HTTP/2.0 use case.
> >>
> >>> I'd say focusing on tls1.3 and any privacy gains there is better
> >>> than diverting effort to NPN to be honest.
> >>
> >> The concern raised by Brian Smith is that if TLS 1.3 is an upgrade to
> >> TLS 1.2 with cleartext ALPN, based on how we understand negotiated
> >> TLS today, then compliant clients may have a strong incentive to
> >> continue to send cleartext ALPN, so that they can negotiate with
> >> servers not yet capable of TLS 1.3.
> >
> > Yep, that is a good question to consider. I don't think I've seen it
> > addressed either, but maybe I missed that.
> >
> >> If we settle on ALPN now, the information in ALPN seems likely to
> >> remain in the clear for lots of handshakes even after TLS 1.3 is
> >> widely deployed.  If one of the goals of TLS 1.3 is encrypting as
> >> much of the handshake as possible (which i think it should be), then
> >> standardizing ALPN now seems to work against the goals of TLS
> >> 1.3 more strongly than any diversion of effort related to NPN.
> >
> > Depends on what ALPN values would be present in a case where tls1.3
> > and http/2.0 are supported. I don't know what'd be likely there.
> >
> > S.
> >
> >>
> >> --dkg
> >>
> >>
> >>
> >> _______________________________________________ TLS mailing
> list
> >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> >>
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.14 (GNU/Linux)
> >
> > iQEcBAEBAgAGBQJSqH77AAoJEC88hzaAX42illgIAJltllnhLB3xGbHF/l6ul3nU
> >
> Mzd8kvF9W27zRoGg0L1noxfQEawGyOjfRFxGXVO3BYHvXMSIfpAOC5vKWPn
> Y/Hlc
> >
> T2ZkklFk9bTq/b7PIJlmSlPTPqBBUCHlZkxxzlO5GeGwjXahOS7M+kc20/ufMHK
> G
> >
> UGScMtzV5cx3fDQBAPBXjU5w9WHNz0LnLrti9q682g11a4nyRNKvPuaa8ujr4O
> na
> >
> dDtGKIk6ITr6DthO5IrhTEdRpR9/AgpR8WrXslMTKldELw6Inf4dBKOOkOJtnptA
> >
> OTbtozBtlyvMQCHSxoVEb0FS5AgXFvTVL9t3SY/1BcYmzvbjvYl/XP1kNI8VTS4=3D
> > =3DJATC
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>=20
>=20
>=20
> --
> Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

From frantz@pwpconsult.com  Thu Dec 12 13:53:10 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22D81AE502 for ; Thu, 12 Dec 2013 13:53:10 -0800 (PST)
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 NbnXgftvB52h for ; Thu, 12 Dec 2013 13:53:08 -0800 (PST)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 706341AD694 for ; Thu, 12 Dec 2013 13:53:08 -0800 (PST)
Received: from [173.75.83.15] (helo=Williams-MacBook-Pro.local) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VrEBp-0001af-DR; Thu, 12 Dec 2013 16:53:01 -0500
Date: Thu, 12 Dec 2013 13:52:56 -0800
From: Bill Frantz 
To: "" 
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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79066ce9d84b5219edf86d03f6cb15cb56350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 173.75.83.15
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 12 Dec 2013 21:53:11 -0000

On 12/11/13 at 3:59 PM, brian@briansmith.org (Brian Smith) wrote:

>On Wed, Dec 11, 2013 at 11:14 AM, Bill Frantz  wrot=
e:
>>We should not insist that a client using the new protocol be able to conn=
ect
>>of a tls 1.2 server (or below) as a result of tls level negotiation. The
>>fallback mechanisms in most browsers can cover that need. The extra desig=
n
>>freedom will allow us to easily encrypt data that was previously sent in =
the
>>clear without worrying about backward compatibility.
>
>I think us browser people might have unintentionally misled people
>about our eagerness to reconnect with downgraded security properties.
>I, and other browser people I know, consider it mis-feature, and we'd
>love to find a way to stop doing it. So, trying to connect via "TLS
>2.0" that has better security/privacy properties, and then insecurely
>falling back to TLS 1.2 with worse security/privacy properties, is
>something that I'd definitely want to avoid.

Obviously, considering the code that is now being shipped, most=20
browser people have held their noses and gone down the retry at=20
lower level path. Functionality over the best security.

Of course until quite recently people thought that SSL3 was=20
reasonably secure, so the odor wasn't quite as bad.


>...
>
>Besides being an ineffective security/privacy measure (since any MitM
>could induce the fallback to from "TLS 2.0" to TLS 1.2), it would also
>be unacceptable due to the added latency for any site that hadn't
>upgraded to "TLS 2.0." We are many years away from that becoming a
>viable thing for us to do.

I view the added latency as a plus. It gives sites an incentive=20
to upgrade.


We are now in the situation where much of the end-user security=20
software is automatically upgraded regularly. The server side=20
software is never* upgraded. To improve net security this=20
situation has to change.

* Yes, it's a bit strong. Google, Facebook etc. are leaders in=20
improving security. However, never applies to the embedded=20
devices using HTTPS for configuration.


Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | If the site is supported by  | Periwinkle
(408)356-8506      | ads, you are the product.    | 16345=20
Englewood Ave
www.pwpconsult.com |                              | Los Gatos,=20
CA 95032


From trevp@trevp.net  Thu Dec 12 16:06:22 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825031AE56A for ; Thu, 12 Dec 2013 16:06:22 -0800 (PST)
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 u4jnmxI1AHip for ; Thu, 12 Dec 2013 16:06:19 -0800 (PST)
Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 108AB1AE19A for ; Thu, 12 Dec 2013 16:06:18 -0800 (PST)
Received: by mail-we0-f182.google.com with SMTP id q59so1228524wes.27 for ; Thu, 12 Dec 2013 16:06:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=gCiZEPnJ4AKEWLIP4X8+DUqu4ppnfxZMPlp3K+1Cz4o=; b=ITtsd9C3ILljlIuzEYslZgpD9lZQDacPOp8UNDrjBVeGPrlJeJjhoFDXA/+Nsv/Auo rTUOkbAh7QX3j048mTndtF5IInz/jwAmtmN65SFx3UD0jOC4JLdRCjwXy7/gB4bZZw8B /h6Bx1TeUIg2dPdGf6jXAsAOD3m2Ydc1Jf3jF610I0Y7SaGDnRgXza2zJvbDXImN+DMm Fmkqax16y4fayomY6aolLwV2buky8hYFhTqUqowxCDO1qDqWc884r2kOUMvcfgVSmfFY X5G8VfPNFS7Svggb9GtKAvT4DGb5ToPb42XoI7rgHqCI+T2jLzALMfRLRkC+M1KfxsUw 4Tqw==
X-Gm-Message-State: ALoCoQm79po+J2ytf9qc13GH9fKiT/UBxCv6oDnHDOgkoDx8gQimkDEAFQG7WtbQIBw8kjji4CPo
MIME-Version: 1.0
X-Received: by 10.194.2.108 with SMTP id 12mr9019827wjt.64.1386893172520; Thu, 12 Dec 2013 16:06:12 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Thu, 12 Dec 2013 16:06:12 -0800 (PST)
X-Originating-IP: [12.27.66.5]
Date: Thu, 12 Dec 2013 16:06:12 -0800
Message-ID: 
From: Trevor Perrin 
To: cfrg@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" , saag@ietf.org
Subject: [TLS] Question regarding CFRG process
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 00:06:22 -0000

Dear CFRG (cc: TLS, SAAG),

I'd like to understand how the CFRG decides on guidance to provide IETF WGs.

It appears the CFRG chairs provide this guidance based on their own
opinions, disregarding any feedback from the mailing list or IETF
meetings.

In particular, the CFRG chairs have repeatedly endorsed the
"Dragonfly" protocol to the TLS WG.  However, I find no evidence of
*ANY* positive feedback regarding Dragonfly in the CFRG mailing list
or meeting minutes, except from the draft's author and CFRG co-chair
Kevin Igoe.

Compared to Kevin's enthusiasm, note:
 * Respected cryptographers and security engineers like Jonathan Katz,
Adam Back, and Rene Struik expressed skepticism on the list
 * The single in-depth discussion at an IETF meeting was a string of complaints
 * Alternative proposals were made to CFRG (J-PAKE, AugPAKE).

Could the chairs please clarify how they decided to endorse Dragonfly to TLS WG?


Below is a summary of all CFRG discussion of Dragonfly.

=====

Feb 2008
 - Dan Harkins proposes early Dragonfly to CFRG
 http://www.ietf.org/mail-archive/web/cfrg/current/msg02205.html

 - Scott Fluhrer breaks it
 http://www.ietf.org/mail-archive/web/cfrg/current/msg02206.html

...

Nov 2011
 - David McGrew appoints Kevin Igoe as CFRG co-chair
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html

Dec 2011
 - Dan Harkins asks CFRG to look at TLS-PWD, based on Dragonfly
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html

 - Scott Fluhrer points out a problem
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03045.html

 - Adam Back questions necessity of it, and lack of security
   analysis
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html

Jan 2012
 - Kevin Igoe's first email to CFRG:
   "I really like this idea & can find no problems."
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html

 - Jonathan Katz questions lack of security analysis, points out
   problems
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html

March 2012
 - At IETF 83 CFRG meeting, concerns are raised about:
   - SPEKE patents
   - necessity of a new scheme
   - timing attacks
   - non-augmented properties
 http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt

May 2012
 - Kevin Igoe points out a limitation due to "hunting-and-pecking"
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html

 - Zhou Sujing and Dan have an exchange that's hard to follow.
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03115.html

July 2012
 - At IETF 84 TLS meeting (CFRG does not meet):
   - Kevin Igoe informs TLS WG, as the CFRG chair:
     "We approve of it, very clear and usable for general setting."
 http://www.ietf.org/proceedings/84/minutes/minutes-84-tls

Oct 2012
 - Kevin Igoe calls CFRG attention to Dragonfly draft-00
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03214.html

 - Jonathan Katz asks for a security proof - there is none
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03215.html
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html

Dec 2012
 - Kevin Igoe calls CFRG attention to Dragonfly
   - raises timing attack issue, proposes 2 fixes, including
     rediscovery of Dan's original broken method (2008)
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html

 - Rene Struik points out the error in Kevin's proposal, and
   the inefficiency of Dragonfly relative to SPEKE
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html

 - Scott Fluhrer points out the error in Kevin's proposal, and
   proposes a flawed "mostly constant time" fix.  Dan and Kevin
   embrace it.
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03260.html
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03263.html
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03265.html

Feb 2013
 - draft-01 is uploaded with flawed sidechannel fix
   - also quietly fixes security issue reported by Dylan Clarke
     and Feng Hao
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03309.html
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03529.html

Apr 2013
 - Kevin Igoe mentions a last call for Dragonfly
   "The design looks mature, it addresses a real need, and no one
    has raised any issues."
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html

May 2013
 - Feng Hao asks CFRG to consider J-PAKE (an alternative)
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html

July 2013
 - Rene Struik points out spec bugs, raises timing attack issue
   again
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03486.html
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html

 - IETF 87, CFRG meeting:
   - "The author is working on a new (and hopefully final) draft"
 http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg

Aug 2013
 - draft-02 is uploaded with modifications to "hunting-and-pecking"
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html

Sep 2013
 - SeongHan Shin asks CFRG to consider AugPAKE (an alternative)
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html

Nov/Dec 2013
 - Joe Saloway begins TLS-PWD last call, and informs TLS WG that:
   "The underlying cryptographic protocol for TLS-PWD has been
   reviewed by the IRTF CFRG group with satisfactory results."
 http://www.ietf.org/mail-archive/web/tls/current/msg10476.html

 - Uproar on TLS WG:

   - Many object to lack of formal security analysis:
     Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik,
     Watson Ladd

   - Many point out better alternatives:
     SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin

   - Security flaws are pointed out by Bodo Moeller and
     CodesInChaos
   http://www.ietf.org/mail-archive/web/tls/current/msg10708.html
   http://www.ietf.org/mail-archive/web/tls/current/msg10768.html

   - Rene Struik and Bodo Moeller dispute that CFRG approved this
   http://www.ietf.org/mail-archive/web/tls/current/msg10769.html
   http://www.ietf.org/mail-archive/web/tls/current/msg10812.html

 - Eric Rescorla (TLS WG chair) states:
   "we did have a verbal report back from the chair of the CFRG
   that they considered it satisfactory"
 http://www.ietf.org/mail-archive/web/tls/current/msg10819.html


Trevor

From ekr@rtfm.com  Thu Dec 12 17:24:40 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B291AE167 for ; Thu, 12 Dec 2013 17:24:40 -0800 (PST)
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 3Ypkwis6lL9D for ; Thu, 12 Dec 2013 17:24:38 -0800 (PST)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id B42D31AE166 for ; Thu, 12 Dec 2013 17:24:36 -0800 (PST)
Received: by mail-wi0-f174.google.com with SMTP id z2so425893wiv.1 for ; Thu, 12 Dec 2013 17:24:30 -0800 (PST)
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:content-transfer-encoding; bh=Wfg63fSZUz0cufWt7uddygjMJfskTcg2C0n5gGXYdlw=; b=dNn1MMjCEq3SCsQgL9CIlccbGdT/jD7162o+U2qvx4X62kcm3a4hRuvy8oy/Z9FbK4 AM98HzzrJ/JuulUEgcCWrSr7wf50ZFAocXjsMfL2AvHZ1jef8LlIiP6Z5WRnKbrx1CVe BxTrazXlg+a0dq9R1JJB9Wdi0AX+bQNJA8+xTL12NWlTb8pAKFbIvsuVqOkgDqxmfnbZ uj8GvhZtG9OV8iM0uUvXC4mmpG8bk3NMPxGI5nh+SrSFBoz5sjvLME3T4RRRhLdSAVT+ wVPj+ZWdHw7ejyNw0boix50oStUGTFaafGjy8SselITsSLQPUCzC+j2Frv1yX1AVleIY tvWA==
X-Gm-Message-State: ALoCoQnjln1ZRRtznTVmshylqIgmzPi2HAYyaW6p/RLnQd299nmVdlAWtkA90dBhU7OV5r5vSD8r
X-Received: by 10.194.60.103 with SMTP id g7mr8966378wjr.37.1386897870156; Thu, 12 Dec 2013 17:24:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Thu, 12 Dec 2013 17:23:49 -0800 (PST)
X-Originating-IP: [118.163.10.190]
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>  <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com>
From: Eric Rescorla 
Date: Fri, 13 Dec 2013 09:23:49 +0800
Message-ID: 
To: "Salz, Rich" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" 
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 01:24:40 -0000

On Thu, Dec 12, 2013 at 11:22 PM, Salz, Rich  wrote:
> I agree with Marsh that PFS should be included.

Can you elaborate more on this? TLS already supports PFS, so are you
arguing we should maintain that support or that we should strip out
all non-PFS cipher suites (see the thread on static RSA...)


> I am concerned about the 'political' emphasis on reducing round trips. On=
e of the arguments heard I hear against 'https everywhere' is that the extr=
a round-trips' cause too much latency and impact customer's web experience.=
 If we can work to reduce RTT without sacrificing security, then that's gre=
at and I would like to see "while maintaining security features" or some su=
ch added.

I have no problem with that. I would have thought it went without saying
but I'm more than happy to have us say it.


> I would like to add a bullet that says backward compatibility with previo=
us  versions is not a requirement. Given all that downgrade fallback issues=
 that continually arise here, we should strongly consider if the right thin=
g to do is just break the chain.

I think this is actually backwards: it's precisely having some sort of secu=
re
backward negotiation that allows for clean deployment. The problem is
that people have screwed up those mechanisms. If we just do a clean
break there is no chance that secure version detection will work.

-Ekr

>         /r$
>
> --
> Principal Security Engineer
> Akamai Technology
> Cambridge, MA
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

From dharkins@lounge.org  Thu Dec 12 17:59:04 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEBF1AE166; Thu, 12 Dec 2013 17:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 rnAh_VoZRG-k; Thu, 12 Dec 2013 17:59:02 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 44C6F1ADFDF; Thu, 12 Dec 2013 17:59:02 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3D74D10224008; Thu, 12 Dec 2013 17:58:56 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 12 Dec 2013 17:58:56 -0800 (PST)
Message-ID: <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net>
In-Reply-To: 
References: 
Date: Thu, 12 Dec 2013 17:58:56 -0800 (PST)
From: "Dan Harkins" 
To: "Trevor Perrin" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org
Subject: Re: [TLS] [saag] Question regarding CFRG process
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 01:59:04 -0000

On Thu, December 12, 2013 4:06 pm, Trevor Perrin wrote:

  ...an extremely misleading email.

  Using pejoratives like "bug", "flaw", and "attack" he attempts a
smear of people, a protocol, and process. In reality there is no
security bug or flaw or attack with dragonfly.

  There is obviously some personal animosity and taste involved
but that is not technical. Read on.

> Dear CFRG (cc: TLS, SAAG),
>
> I'd like to understand how the CFRG decides on guidance to provide IETF
> WGs.
>
> It appears the CFRG chairs provide this guidance based on their own
> opinions, disregarding any feedback from the mailing list or IETF
> meetings.
>
> In particular, the CFRG chairs have repeatedly endorsed the
> "Dragonfly" protocol to the TLS WG.  However, I find no evidence of
> *ANY* positive feedback regarding Dragonfly in the CFRG mailing list
> or meeting minutes, except from the draft's author and CFRG co-chair
> Kevin Igoe.
>
> Compared to Kevin's enthusiasm, note:
>  * Respected cryptographers and security engineers like Jonathan Katz,
> Adam Back, and Rene Struik expressed skepticism on the list

  Let's look at those, read on.

>  * The single in-depth discussion at an IETF meeting was a string of
> complaints

  That's what comments are. And they get addressed.

>  * Alternative proposals were made to CFRG (J-PAKE, AugPAKE).
>
> Could the chairs please clarify how they decided to endorse Dragonfly to
> TLS WG?
>
>
> Below is a summary of all CFRG discussion of Dragonfly.
>
> =====
>
> Feb 2008
>  - Dan Harkins proposes early Dragonfly to CFRG
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg02205.html
>
>  - Scott Fluhrer breaks it
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg02206.html

  An event mentioned in the acknowledgments. Thank you Scott.
His review and comments have been most helpful.

>
> Nov 2011
>  - David McGrew appoints Kevin Igoe as CFRG co-chair
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html

  Completely and utterly irrelevant.

> Dec 2011
>  - Dan Harkins asks CFRG to look at TLS-PWD, based on Dragonfly
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html
>
>  - Scott Fluhrer points out a problem
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03045.html

  A simple "sanity" check that the an ECC point is not "infinity". Again,
a good comment.

>  - Adam Back questions necessity of it, and lack of security
>    analysis
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html

  He does no such thing. He notices that SRP is not mentioned in the
draft. Quite true. And he asks what key exchange is being implemented
because "its harder than it looks". Which is also quite true.

> Jan 2012
>  - Kevin Igoe's first email to CFRG:
>    "I really like this idea & can find no problems."
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html
>
>  - Jonathan Katz questions lack of security analysis, points out
>    problems
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html

  Yes, helpful comments on the draft. The susceptibility to attack under
the random oracle model is, in fact, mentioned in my slide deck when
I presented to the CFRG in Paris at IETF 83. It is a highly contrived
scenario and completely unlikely a real world protocol but it does raise
the question of making a formal proof in that model.

  You should link to my slide deck in your next broadside.

> March 2012
>  - At IETF 83 CFRG meeting, concerns are raised about:
>    - SPEKE patents
>    - necessity of a new scheme
>    - timing attacks
>    - non-augmented properties
>  http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt

  Wow, you make it sound as if you were there. But you weren't. And
your summary is not an accurate description of the meeting. The
sole mention in the minutes of SPEKE is from me. And the "concerns"
are a recitation of comments received. That's how it works. You get
comments and you resolve them.

> May 2012
>  - Kevin Igoe points out a limitation due to "hunting-and-pecking"
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html

  He does no such thing. He just said that if the prime defining the
curve p = 3 mod 4 that it's easier to compute the square root.

>  - Zhou Sujing and Dan have an exchange that's hard to follow.
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03115.html
>
> July 2012
>  - At IETF 84 TLS meeting (CFRG does not meet):
>    - Kevin Igoe informs TLS WG, as the CFRG chair:
>      "We approve of it, very clear and usable for general setting."
>  http://www.ietf.org/proceedings/84/minutes/minutes-84-tls

  Also note the comment: "Tie Dragonfly into EST would be very useful"
Yes, it would.

> Oct 2012
>  - Kevin Igoe calls CFRG attention to Dragonfly draft-00
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03214.html
>
>  - Jonathan Katz asks for a security proof - there is none
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03215.html
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html

  Correct. There is no formal proof of security. See my slides from
IETF 83.

> Dec 2012
>  - Kevin Igoe calls CFRG attention to Dragonfly
>    - raises timing attack issue, proposes 2 fixes, including
>      rediscovery of Dan's original broken method (2008)
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html

  This is further discussion on addressing a side channel attack.
Your attempt to spin this as "broken" is somewhat desperate.

>  - Rene Struik points out the error in Kevin's proposal, and
>    the inefficiency of Dragonfly relative to SPEKE
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html

  He does no such thing. His "Suppose A and B…" is a recitation of
a version of SPEKE that does not hash the password into a group in
the domain parameter set. It's neither here nor there with respect
to dragonfly. He further goes on to suggest on a check for "point at
infinity". Which is already part of dragonfly.

  There is no "error" noted and no "inefficiency" mentioned either.

>  - Scott Fluhrer points out the error in Kevin's proposal, and
>    proposes a flawed "mostly constant time" fix.  Dan and Kevin
>    embrace it.
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03260.html
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03263.html
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03265.html

  As noted in the email thread, the described fix was added to the
draft at the time. Your opinion on it being "flawed" has already been
noted.

> Feb 2013
>  - draft-01 is uploaded with flawed sidechannel fix
>    - also quietly fixes security issue reported by Dylan Clarke
>      and Feng Hao
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03309.html
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03529.html

  This is a small sub-group attack possible if one does not check
validity of received elements. All incarnations of dragonfly-- TLS-PWD,
EAP-PWD and 802.11 already did this. It is entirely my fault that I left that
crucial step out of the -00 version of the CFRG draft but it is hardly
a flaw.

> Apr 2013
>  - Kevin Igoe mentions a last call for Dragonfly
>    "The design looks mature, it addresses a real need, and no one
>     has raised any issues."
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html

  That's correct. You are included in that "no one".

> May 2013
>  - Feng Hao asks CFRG to consider J-PAKE (an alternative)
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html

  Completely irrelevant.

> July 2013
>  - Rene Struik points out spec bugs, raises timing attack issue
>    again
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03486.html
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html

  "Spec bugs", in other words typos. Yes, he brings up an issue that
had previously been addressed.

>  - IETF 87, CFRG meeting:
>    - "The author is working on a new (and hopefully final) draft"
>  http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg

  Sadly, it's not. I have to address the "Spec bugs" and address
Rene's other comments, none of which demonstrate security flaws.

> Aug 2013
>  - draft-02 is uploaded with modifications to "hunting-and-pecking"
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html

  Don't forget comments dealing with internationalization!

  The change is from a comment received from, if I recall, Russ Housley
to use the technique from FIPS 186-3 to hide the bias added by the
modular reduction. Again, a very nice comment, happily accepted.

> Sep 2013
>  - SeongHan Shin asks CFRG to consider AugPAKE (an alternative)
>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html

  Completely irrelevant. (Again, not sure why you're have become such
a cheerleader for AugPAKE).

> Nov/Dec 2013
>  - Joe Saloway begins TLS-PWD last call, and informs TLS WG that:
>    "The underlying cryptographic protocol for TLS-PWD has been
>    reviewed by the IRTF CFRG group with satisfactory results."
>  http://www.ietf.org/mail-archive/web/tls/current/msg10476.html
>
>  - Uproar on TLS WG:
>
>    - Many object to lack of formal security analysis:
>      Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik,
>      Watson Ladd

  Missing, of course, the caveat "-- except I believe that whenever
possible the IETF should aim to standardize cryptographic protocols
that are unencumbered by license fees and patents. If the choice
arises between a protocol that carries both (provable security and
Intellectual Property) and a protocol that has neither - I'd strongly
prefer the latter."

>    - Many point out better alternatives:
>      SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin

  And you're all free to write up Internet Drafts on them too!

  In fact, SeongHan Shin has been following me around EMU, IPsec,
CFRG and now TLS doing just that. After I write a dragonfly I-D he
writes an AugPAKE I-D. Nothing is stopping you from doing it too.

>    - Security flaws are pointed out by Bodo Moeller and
>      CodesInChaos
>    http://www.ietf.org/mail-archive/web/tls/current/msg10708.html
>    http://www.ietf.org/mail-archive/web/tls/current/msg10768.html

  Bodo's comment has been addressed. I dispute the use of the term
"security flaw" to describe it but that is consistent with the rest of
your email.

  CodesInChaos suggested using PBKDF2 to hash the password. This
really provides no additional benefit,, as I noted in a subsequent
email (see coWPAtty and family attacks against a protocol that uses
PBKDF2).

>    - Rene Struik and Bodo Moeller dispute that CFRG approved this
>    http://www.ietf.org/mail-archive/web/tls/current/msg10769.html
>
>    http://www.ietf.org/mail-archive/web/tls/current/msg10812.html

  Actually, Rene notes that CFRG has not issued a LC. He does raise
some comments, many of which are already addressed in the draft
and he points out the "Spec bug" you allude to earlier. He suggests
relaxation of one of the restrictions on parameter generation that I
decline to accept. And he finds some additional typos and an
erroneous description of point addition. Helpful comments.

>  - Eric Rescorla (TLS WG chair) states:
>    "we did have a verbal report back from the chair of the CFRG
>    that they considered it satisfactory"
>  http://www.ietf.org/mail-archive/web/tls/current/msg10819.html

  Indeed.

  So what you've brought up is that there has been discussion of
dragonfly on the list and it has, in fact, been reviewed. Quite a few
comments have been made and resolved, security critical issues have
been raised and properly addressed.

  There are no flaws in the key exchange. It has some aspects to it
that some may feel is a benefit and some may feel is a detriment.
Personal taste is not something that can be universally accommodated.

  Nothing you have raised here is reason to stop advancement of
this draft.

  Dan.



From rsalz@akamai.com  Thu Dec 12 18:57:09 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE681AE5EE for ; Thu, 12 Dec 2013 18:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 CExSTMz1lije for ; Thu, 12 Dec 2013 18:57:07 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1631AE5EB for ; Thu, 12 Dec 2013 18:57:07 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BCE7E284E6; Fri, 13 Dec 2013 02:57:00 +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 A8D6D284E4; Fri, 13 Dec 2013 02:57:00 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id DC2E5206C; Fri, 13 Dec 2013 02:56:59 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.14]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Thu, 12 Dec 2013 21:56:59 -0500
From: "Salz, Rich" 
To: Patrick McManus 
Date: Thu, 12 Dec 2013 21:56:58 -0500
Thread-Topic: [TLS] TLS Charter Revision
Thread-Index: Ac73UzE7HE9HJ2wvQ++CAcQGI6+mKQAWypfg
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711E4675283@USMBX1.msg.corp.akamai.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>  <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com> <3A9A4169-6B5E-453E-930A-F00291B541F4@apple.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: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C711E4675283USMBX1msgcorp_"
MIME-Version: 1.0
Cc: "" 
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 02:57:09 -0000

--_000_2A0EFB9C05D0164E98F19BB0AF3708C711E4675283USMBX1msgcorp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=D8  Time to first byte is extremely important to web content

Sure,  but it's not the only thing (and I know you're not saying it is). I'=
m all in favor of a robust discussion of the trade-offs. After all, we gene=
rally approve of having speed limits on our roads.
--
Principal Security Engineer
Akamai Technology
Cambridge, MA


--_000_2A0EFB9C05D0164E98F19BB0AF3708C711E4675283USMBX1msgcorp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



=D8  Time to first byte is extremely important to web=
 content
 
S=
ure,=A0 but it’s not the only thing (and I know you’re not sayi=
ng it is). I’m all in favor of a robust discussion of the trade-offs.=
 After all, we generally approve of having speed limits on our roads.<=
/o:p>
--=A0 
Principal Security Engineer
<=
p class=3DMsoNormal>Akamai Technology
Cambridge, MA
 
=

--_000_2A0EFB9C05D0164E98F19BB0AF3708C711E4675283USMBX1msgcorp_--

From watsonbladd@gmail.com  Thu Dec 12 19:36:58 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8C41AE14F; Thu, 12 Dec 2013 19:36:58 -0800 (PST)
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 hh5g-s88wsjz; Thu, 12 Dec 2013 19:36:54 -0800 (PST)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DA9E11AE144; Thu, 12 Dec 2013 19:36:53 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id m15so1304684wgh.1 for ; Thu, 12 Dec 2013 19:36:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AmjN9HixemacuMojngKj07AsfXx5XuNoRBpnyhLcyn4=; b=myV7MZik1vImIUQfWcvXXAfzntYzjxbiH0YhS7x9rVzfGrnWdxuwxEnxHa6bjiGHbc iiyYVIN1BFVeEpamHRdAYRcjwu61f72ZYKPvzNB6iXr9VO05l4YpTTnMcQuvbQAsqLzm 4toW7oxQsROgptxtnBPms9aOiWgsemdlEzpmgCi7wdSyBwfiaRUmmU7AxmZF6xeSPlbL i8pyzIuhSB2inDKLDoglH5NbH/NFmbQSYTI/Y7A0F52VHwipexGE1RQ/XD6NK9azVZ8/ sDU+9a88cbYUAEo9v3DD/obrDDahVBnebHnhA4JqZBXLzVvKy0sqdnxfGqsm6qIs8bGY lZfA==
MIME-Version: 1.0
X-Received: by 10.194.85.75 with SMTP id f11mr298634wjz.14.1386905807294; Thu, 12 Dec 2013 19:36:47 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Thu, 12 Dec 2013 19:36:47 -0800 (PST)
In-Reply-To: <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net>
References:  <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net>
Date: Thu, 12 Dec 2013 19:36:47 -0800
Message-ID: 
From: Watson Ladd 
To: Dan Harkins 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org
Subject: Re: [TLS] [saag] Question regarding CFRG process
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 03:36:58 -0000

On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins  wrote:
>
> On Thu, December 12, 2013 4:06 pm, Trevor Perrin wrote:
>
>   ...an extremely misleading email.
>
>   Using pejoratives like "bug", "flaw", and "attack" he attempts a
> smear of people, a protocol, and process. In reality there is no
> security bug or flaw or attack with dragonfly.
>
>   There is obviously some personal animosity and taste involved
> but that is not technical. Read on.
This is not quite true. Dragonfly's vaunted resistance to offline
attack doesn't hold
in the standard model or the ROM because there are some hash functions
(like hashing+exponentiation)
which break it. This is a very serious issue: it means we don't know
what it means for Dragonfly to be secure.

>
>> Dear CFRG (cc: TLS, SAAG),
>>
>> I'd like to understand how the CFRG decides on guidance to provide IETF
>> WGs.
>>
>> It appears the CFRG chairs provide this guidance based on their own
>> opinions, disregarding any feedback from the mailing list or IETF
>> meetings.
>>
>> In particular, the CFRG chairs have repeatedly endorsed the
>> "Dragonfly" protocol to the TLS WG.  However, I find no evidence of
>> *ANY* positive feedback regarding Dragonfly in the CFRG mailing list
>> or meeting minutes, except from the draft's author and CFRG co-chair
>> Kevin Igoe.
>>
>> Compared to Kevin's enthusiasm, note:
>>  * Respected cryptographers and security engineers like Jonathan Katz,
>> Adam Back, and Rene Struik expressed skepticism on the list
>
>   Let's look at those, read on.
>
>>  * The single in-depth discussion at an IETF meeting was a string of
>> complaints
>
>   That's what comments are. And they get addressed.
>
>>  * Alternative proposals were made to CFRG (J-PAKE, AugPAKE).
>>
>> Could the chairs please clarify how they decided to endorse Dragonfly to
>> TLS WG?
>>
>>
>> Below is a summary of all CFRG discussion of Dragonfly.
>>
>> =3D=3D=3D=3D=3D
>>
>> Feb 2008
>>  - Dan Harkins proposes early Dragonfly to CFRG
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg02205.html
>>
>>  - Scott Fluhrer breaks it
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg02206.html
>
>   An event mentioned in the acknowledgments. Thank you Scott.
> His review and comments have been most helpful.
>
>>
>> Nov 2011
>>  - David McGrew appoints Kevin Igoe as CFRG co-chair
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html
>
>   Completely and utterly irrelevant.
>
>> Dec 2011
>>  - Dan Harkins asks CFRG to look at TLS-PWD, based on Dragonfly
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html
>>
>>  - Scott Fluhrer points out a problem
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03045.html
>
>   A simple "sanity" check that the an ECC point is not "infinity". Again,
> a good comment.
>
>>  - Adam Back questions necessity of it, and lack of security
>>    analysis
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html
>
>   He does no such thing. He notices that SRP is not mentioned in the
> draft. Quite true. And he asks what key exchange is being implemented
> because "its harder than it looks". Which is also quite true.
>
>> Jan 2012
>>  - Kevin Igoe's first email to CFRG:
>>    "I really like this idea & can find no problems."
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html
>>
>>  - Jonathan Katz questions lack of security analysis, points out
>>    problems
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html
>
>   Yes, helpful comments on the draft. The susceptibility to attack under
> the random oracle model is, in fact, mentioned in my slide deck when
> I presented to the CFRG in Paris at IETF 83. It is a highly contrived
> scenario and completely unlikely a real world protocol but it does raise
> the question of making a formal proof in that model.
On the contrary: "it looks secure to me" is not an acceptable foundation fo=
r
cryptographic protocols. I do not want any protocol I approve to be a CRYPT=
O
keynote in the future.
>
>   You should link to my slide deck in your next broadside.
>
>> March 2012
>>  - At IETF 83 CFRG meeting, concerns are raised about:
>>    - SPEKE patents
>>    - necessity of a new scheme
>>    - timing attacks
>>    - non-augmented properties
>>  http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt
>
>   Wow, you make it sound as if you were there. But you weren't. And
> your summary is not an accurate description of the meeting. The
> sole mention in the minutes of SPEKE is from me. And the "concerns"
> are a recitation of comments received. That's how it works. You get
> comments and you resolve them.
>
>> May 2012
>>  - Kevin Igoe points out a limitation due to "hunting-and-pecking"
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html
>
>   He does no such thing. He just said that if the prime defining the
> curve p =3D 3 mod 4 that it's easier to compute the square root.
>
>>  - Zhou Sujing and Dan have an exchange that's hard to follow.
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03115.html
>>
>> July 2012
>>  - At IETF 84 TLS meeting (CFRG does not meet):
>>    - Kevin Igoe informs TLS WG, as the CFRG chair:
>>      "We approve of it, very clear and usable for general setting."
>>  http://www.ietf.org/proceedings/84/minutes/minutes-84-tls
>
>   Also note the comment: "Tie Dragonfly into EST would be very useful"
> Yes, it would.
>
>> Oct 2012
>>  - Kevin Igoe calls CFRG attention to Dragonfly draft-00
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03214.html
>>
>>  - Jonathan Katz asks for a security proof - there is none
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03215.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html
>
>   Correct. There is no formal proof of security. See my slides from
> IETF 83.
>
>> Dec 2012
>>  - Kevin Igoe calls CFRG attention to Dragonfly
>>    - raises timing attack issue, proposes 2 fixes, including
>>      rediscovery of Dan's original broken method (2008)
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html
>
>   This is further discussion on addressing a side channel attack.
> Your attempt to spin this as "broken" is somewhat desperate.
Modern cryptographic practice demands constant time, jump-free,
no variable memory access cryptography.
>
>>  - Rene Struik points out the error in Kevin's proposal, and
>>    the inefficiency of Dragonfly relative to SPEKE
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html
>
>   He does no such thing. His "Suppose A and B=E2=80=A6" is a recitation o=
f
> a version of SPEKE that does not hash the password into a group in
> the domain parameter set. It's neither here nor there with respect
> to dragonfly. He further goes on to suggest on a check for "point at
> infinity". Which is already part of dragonfly.
>
>   There is no "error" noted and no "inefficiency" mentioned either.
>
>>  - Scott Fluhrer points out the error in Kevin's proposal, and
>>    proposes a flawed "mostly constant time" fix.  Dan and Kevin
>>    embrace it.
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03260.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03263.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03265.html
>
>   As noted in the email thread, the described fix was added to the
> draft at the time. Your opinion on it being "flawed" has already been
> noted.
>
>> Feb 2013
>>  - draft-01 is uploaded with flawed sidechannel fix
>>    - also quietly fixes security issue reported by Dylan Clarke
>>      and Feng Hao
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03309.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03529.html
>
>   This is a small sub-group attack possible if one does not check
> validity of received elements. All incarnations of dragonfly-- TLS-PWD,
> EAP-PWD and 802.11 already did this. It is entirely my fault that I left =
that
> crucial step out of the -00 version of the CFRG draft but it is hardly
> a flaw.
>
>> Apr 2013
>>  - Kevin Igoe mentions a last call for Dragonfly
>>    "The design looks mature, it addresses a real need, and no one
>>     has raised any issues."
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html
>
>   That's correct. You are included in that "no one".
>
>> May 2013
>>  - Feng Hao asks CFRG to consider J-PAKE (an alternative)
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html
>
>   Completely irrelevant.
>
I don't think so. Your repeated insistence to the contrary, there are peopl=
e who
will use RC4 on TLS connections, etc, etc. Our endorsing a protocol
when superior
alternatives exist is a bad thing, because insecure options have a
nasty habit of being
turned on. You've argued that because you and your employer don't see
an issue, we should
be happy to endorse this.
>> July 2013
>>  - Rene Struik points out spec bugs, raises timing attack issue
>>    again
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03486.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html
>
>   "Spec bugs", in other words typos. Yes, he brings up an issue that
> had previously been addressed.
>
>>  - IETF 87, CFRG meeting:
>>    - "The author is working on a new (and hopefully final) draft"
>>  http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg
>
>   Sadly, it's not. I have to address the "Spec bugs" and address
> Rene's other comments, none of which demonstrate security flaws.
>
>> Aug 2013
>>  - draft-02 is uploaded with modifications to "hunting-and-pecking"
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html
>
>   Don't forget comments dealing with internationalization!
>
>   The change is from a comment received from, if I recall, Russ Housley
> to use the technique from FIPS 186-3 to hide the bias added by the
> modular reduction. Again, a very nice comment, happily accepted.
Knuth discusses this in detail in Volume 2. Bleichenbacher got a lot
of mileage from
this.
>
>> Sep 2013
>>  - SeongHan Shin asks CFRG to consider AugPAKE (an alternative)
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html
>
>   Completely irrelevant. (Again, not sure why you're have become such
> a cheerleader for AugPAKE).
>
>> Nov/Dec 2013
>>  - Joe Saloway begins TLS-PWD last call, and informs TLS WG that:
>>    "The underlying cryptographic protocol for TLS-PWD has been
>>    reviewed by the IRTF CFRG group with satisfactory results."
>>  http://www.ietf.org/mail-archive/web/tls/current/msg10476.html
>>
>>  - Uproar on TLS WG:
>>
>>    - Many object to lack of formal security analysis:
>>      Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik,
>>      Watson Ladd
>
>   Missing, of course, the caveat "-- except I believe that whenever
> possible the IETF should aim to standardize cryptographic protocols
> that are unencumbered by license fees and patents. If the choice
> arises between a protocol that carries both (provable security and
> Intellectual Property) and a protocol that has neither - I'd strongly
> prefer the latter."
>
>>    - Many point out better alternatives:
>>      SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin
>
>   And you're all free to write up Internet Drafts on them too!
Why do you want Dragonfly as opposed to J-PAKE? If you think it is
going to slow, call up Feng Hao and offer to help. That would satisfy the
need you identify in your usecase in the TLS WG.
Or is this not about solving the problem of password authenticated key exch=
ange,
but putting your protocol into things?
>
>   In fact, SeongHan Shin has been following me around EMU, IPsec,
> CFRG and now TLS doing just that. After I write a dragonfly I-D he
> writes an AugPAKE I-D. Nothing is stopping you from doing it too.
>
>>    - Security flaws are pointed out by Bodo Moeller and
>>      CodesInChaos
>>    http://www.ietf.org/mail-archive/web/tls/current/msg10708.html
>>    http://www.ietf.org/mail-archive/web/tls/current/msg10768.html
>
>   Bodo's comment has been addressed. I dispute the use of the term
> "security flaw" to describe it but that is consistent with the rest of
> your email.
>
>   CodesInChaos suggested using PBKDF2 to hash the password. This
> really provides no additional benefit,, as I noted in a subsequent
> email (see coWPAtty and family attacks against a protocol that uses
> PBKDF2).
>
>>    - Rene Struik and Bodo Moeller dispute that CFRG approved this
>>    http://www.ietf.org/mail-archive/web/tls/current/msg10769.html
>>
>>    http://www.ietf.org/mail-archive/web/tls/current/msg10812.html
>
>   Actually, Rene notes that CFRG has not issued a LC. He does raise
> some comments, many of which are already addressed in the draft
> and he points out the "Spec bug" you allude to earlier. He suggests
> relaxation of one of the restrictions on parameter generation that I
> decline to accept. And he finds some additional typos and an
> erroneous description of point addition. Helpful comments.
>
>>  - Eric Rescorla (TLS WG chair) states:
>>    "we did have a verbal report back from the chair of the CFRG
>>    that they considered it satisfactory"
>>  http://www.ietf.org/mail-archive/web/tls/current/msg10819.html
>
>   Indeed.
>
>   So what you've brought up is that there has been discussion of
> dragonfly on the list and it has, in fact, been reviewed. Quite a few
> comments have been made and resolved, security critical issues have
> been raised and properly addressed.
Sorry, but review is not enough. Approval is. What standard is the
chair applying here?
>
>   There are no flaws in the key exchange. It has some aspects to it
> that some may feel is a benefit and some may feel is a detriment.
> Personal taste is not something that can be universally accommodated.
>
>   Nothing you have raised here is reason to stop advancement of
> this draft.
I disagree. This draft is reminiscent of the worst of 90's
cryptography: ad-hoc assumptions,
no formal statement of security, gratuitously not a circuit, and not
subject by review by anyone
who is a cryptographer. It may be that this draft has exposed a fault
line between those who think
the current process is acceptable and those who do not.

>
>   Dan.
>
>
> _______________________________________________
> 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 watsonbladd@gmail.com  Thu Dec 12 19:38:14 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A961AE114 for ; Thu, 12 Dec 2013 19:38:14 -0800 (PST)
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 GP7ckHsGncuR for ; Thu, 12 Dec 2013 19:38:12 -0800 (PST)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4915F1AE0EE for ; Thu, 12 Dec 2013 19:38:12 -0800 (PST)
Received: by mail-wi0-f178.google.com with SMTP id bz8so496139wib.11 for ; Thu, 12 Dec 2013 19:38:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zcBWpAEVrdj4eEDdCfqqNYuijbX211q9KU4Yba7e2Eo=; b=oW7q5zSlcdp7L1J2s6OcG0FbwQSMdkaWEnRe5+beye8Xi/NmvwszQ/VXbaO40FSfdC AzacboQ6anxxw7twnRIL2t2J6ndTNC4gjZIWc5DhsyN9EipHAjfyYVRLZBtjuMCYOZjo HJEWJCI1RDMoJ//xgdYxqYyPImkkn77fVE5w1vnGB4Va/tHko/PrXCGqhFpo5Mj7eA9Q VsmMYu1WjWDtuFo8d2seT8eFi7OR4Ubu8duZ1xLDLKlJ0g4xjME1KKNKfGRbkwo7rm0d 0uUTqMCC6HMx+NW4FovcZN8Bkx6erhRO0s0MPJ0qz4ZHkt5mHYf27SBDn+COmRfY6xTr iZWQ==
MIME-Version: 1.0
X-Received: by 10.194.120.164 with SMTP id ld4mr191980wjb.47.1386905885727; Thu, 12 Dec 2013 19:38:05 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Thu, 12 Dec 2013 19:38:05 -0800 (PST)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711E4675283@USMBX1.msg.corp.akamai.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>  <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com> <3A9A4169-6B5E-453E-930A-F00291B541F4@apple.com>  <2A0EFB9C05D0164E98F19BB0AF3708C711E4675283@USMBX1.msg.corp.akamai.com>
Date: Thu, 12 Dec 2013 19:38:05 -0800
Message-ID: 
From: Watson Ladd 
To: "Salz, Rich" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" 
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 03:38:14 -0000

On Thu, Dec 12, 2013 at 6:56 PM, Salz, Rich  wrote:
> =C3=98  Time to first byte is extremely important to web content
>
>
>
> Sure,  but it=E2=80=99s not the only thing (and I know you=E2=80=99re not=
 saying it is). I=E2=80=99m
> all in favor of a robust discussion of the trade-offs. After all, we
> generally approve of having speed limits on our roads.
TLS could be one round trip if we were willing to eliminate a bunch of
options. I think we should have
a discussion aimed at seeing what we can chop out to reduce the need
for negotiation.
>
> --
>
> Principal Security Engineer
>
> Akamai Technology
>
> Cambridge, MA
>
>
>
>
> _______________________________________________
> 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 brian@briansmith.org  Thu Dec 12 21:15:32 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143A21AE64F for ; Thu, 12 Dec 2013 21:15:32 -0800 (PST)
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, HTML_MESSAGE=0.001, 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 7OlDdenFmMfn for ; Thu, 12 Dec 2013 21:15:29 -0800 (PST)
Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id A04441AE64D for ; Thu, 12 Dec 2013 21:15:29 -0800 (PST)
Received: by mail-qc0-f181.google.com with SMTP id e9so1153235qcy.12 for ; Thu, 12 Dec 2013 21:15:23 -0800 (PST)
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=qKZMO9jHq9EKQm1uk4UqrF4EXkrA5Bp2BYEXoflxo8w=; b=Zfp2Pq6mt96e6WQcG/n8XmVSd5ugRY/IZRNNggtykARJmptA6DGffGrk309NfTSCUl NI7v61Er/OkmLEruFQHAleT8n/uQ+4RVzYgdlUYEB7wduYW3kI2Kdmqx+SoL5d2VN55d oqLKFgguTfcn0tEU10LkVkYkDZxzbRjAtSbwU8gDV/qfkPdlFJo7Qz/j3wg9a3DoiAPs krgHcWSFEZmSHXzm9RHZi2uh9nsnaRfQGexgBu/rUebpmsSzbr4tf1KVMJqbfymEIZmB pra6T5KEo4IaaNfoF7xE5ZEw0V/EBcW2ATU1OyhIYlJo4tOkr9K3/jT0CUbiMzhYkvtc nmAA==
X-Gm-Message-State: ALoCoQm2yNFE8LBvVWaN3qvw80kWkCO+/GAsdFx10bh2Fcj60R7MFuZc+cK0rNFwboqHE/qIuYPw
MIME-Version: 1.0
X-Received: by 10.49.24.211 with SMTP id w19mr1131987qef.9.1386911723240; Thu, 12 Dec 2013 21:15:23 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Thu, 12 Dec 2013 21:15:23 -0800 (PST)
X-Originating-IP: [63.245.219.54]
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>  <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com>
Date: Thu, 12 Dec 2013 21:15:23 -0800
Message-ID: 
From: Brian Smith 
To: "Salz, Rich" 
Content-Type: multipart/alternative; boundary=047d7b67795c99526304ed638cea
Cc: "" 
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 05:15:32 -0000

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

On Thu, Dec 12, 2013 at 7:22 AM, Salz, Rich  wrote:

> I am concerned about the 'political' emphasis on reducing round trips. One
> of the arguments heard I hear against 'https everywhere' is that the extra
> round-trips' cause too much latency and impact customer's web experience.
> If we can work to reduce RTT without sacrificing security, then that's
> great and I would like to see "while maintaining security features" or some
> such added.
>

Rich,

I think you make a very good point. I'd like to clarify, though, that at
least the 1-RTT full handshake proposals are actually not just about
increasing performance, but also about increasing security. A 1-RTT full
handshake improves performance over the case where the client does not use
the TLS False Start mechanism. A new 1-RTT full handshake will improve
security over the case when a client *does* use False Start. (It turns out
that there are more practical security considerations with False Start than
seemed to be the case at first.) Also, a new 1-RTT handshake has the
potential to improve privacy/confidentiality of information in the
handshake. Finally, the 1-RTT handshake would make it esaier to deploy TLS
because it reduces the need for distributed session caches or distributed
session ticket keys--if you're happy to pay the CPU cost of full
handshakes, but not the latency cost of 2-RTTs, then per-host sessions may
work just fine for you.

Consequently, I see the 1-RTT handshake as improving security, privacy,
performance, and ease of deployment at the very small cost of some reduced
flexibility. (But, you get that flexibility back by falling back to the
2-RTT full handshake.)

The 0-RTT handshake ideas I've seen are a little different. There, we may
have to make a security/performance tradeoff, because there are more ways
where an operational failure can make things go bad. I suspect that server
admins will have to decide whether to make this tradeoff or not, after
we've done all we can do to minimize the associated security risks in the
protocol definition. In other words, I think that we should consider
features that have reasonable security tradeoffs, but we should make those
features optional.


> I would like to add a bullet that says backward compatibility with
> previous versions is not a requirement. Given all that downgrade fallback
> issues that continually arise here, we should strongly consider if the
> right thing to do is just break the chain.
>

If there is a way to avoid requiring backward compatibility, that doesn't
add latency when the server only speaks current versions of TLS, then it is
something to consider. But, at least browsers need to work with existing
SSL 3.0-TLS 1.2 servers, without performance regressions, for many years to
come. That leads me to think that the ClientHello message must be backward
compatible with older versions of TLS, at least.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

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


On T=
hu, Dec 12, 2013 at 7:22 AM, Salz, Rich <rsalz@akamai.com> wr=
ote:

I am concerned about the 'political' emphasis on reducing round tri=
ps. One of the arguments heard I hear against 'https everywhere' is=
 that the extra round-trips' cause too much latency and impact customer=
's web experience. If we can work to reduce RTT without sacrificing sec=
urity, then that's great and I would like to see "while maintainin=
g security features" or some such added.



Rich,

I think you make a=
 very good point. I'd like to clarify, though, that at least the 1-RTT =
full handshake proposals are actually not just about increasing performance=
, but also about increasing security. A 1-RTT full handshake improves perfo=
rmance over the case where the client does not use the TLS False Start mech=
anism. A new 1-RTT full handshake will improve security over the case when =
a client *does* use False Start. (It turns out that there are more practica=
l security considerations with False Start than seemed to be the case at fi=
rst.) Also, a new 1-RTT handshake has the potential to improve privacy/conf=
identiality of information in the handshake. Finally, the 1-RTT handshake w=
ould make it esaier to deploy TLS because it reduces the need for distribut=
ed session caches or distributed session ticket keys--if you're happy t=
o pay the CPU cost of full handshakes, but not the latency cost of 2-RTTs, =
then per-host sessions may work just fine for you.


Consequently, I see the 1-RTT handshake as improving security, privacy,=
 performance, and ease of deployment at the very small cost of some reduced=
 flexibility. (But, you get that flexibility back by falling back to the 2-=
RTT full handshake.)


The 0-RTT handshake ideas I've seen are a little differe=
nt. There, we may have to make a security/performance tradeoff, because the=
re are more ways where an operational failure can make things go bad. I sus=
pect that server admins will have to decide whether to make this tradeoff o=
r not, after we've done all we can do to minimize the associated securi=
ty risks in the protocol definition. In other words, I think that we should=
 consider features that have reasonable security tradeoffs, but we should m=
ake those features optional.


=C2=A0


I would like to add a bullet that says backward compatibility with previous=
 versions is not a requirement. Given all that downgrade fallback issues th=
at continually arise here, we should strongly consider if the right thing t=
o do is just break the chain.



If there is a way to avoid requiring backw=
ard compatibility, that doesn't add latency when the server only speaks=
 current versions of TLS, then it is something to consider. But, at least b=
rowsers need to work with existing SSL 3.0-TLS 1.2 servers, without perform=
ance regressions, for many years to come. That leads me to think that the C=
lientHello message must be backward compatible with older versions of TLS, =
at least.


Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)=





--047d7b67795c99526304ed638cea--

From dharkins@lounge.org  Thu Dec 12 23:15:25 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6021AE17C; Thu, 12 Dec 2013 23:15:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 SBm3wehTu4t4; Thu, 12 Dec 2013 23:15:18 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 380DA1AE15F; Thu, 12 Dec 2013 23:15:18 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id F258A10224008; Thu, 12 Dec 2013 23:15:11 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 12 Dec 2013 23:15:12 -0800 (PST)
Message-ID: 
In-Reply-To: 
References:  <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net> 
Date: Thu, 12 Dec 2013 23:15:12 -0800 (PST)
From: "Dan Harkins" 
To: "Watson Ladd" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org
Subject: Re: [TLS] [saag] Question regarding CFRG process
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 07:15:25 -0000

On Thu, December 12, 2013 7:36 pm, Watson Ladd wrote:
> On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins  wrote:
>>
>> On Thu, December 12, 2013 4:06 pm, Trevor Perrin wrote:
>>
>>   ...an extremely misleading email.
>>
>>   Using pejoratives like "bug", "flaw", and "attack" he attempts a
>> smear of people, a protocol, and process. In reality there is no
>> security bug or flaw or attack with dragonfly.
>>
>>   There is obviously some personal animosity and taste involved
>> but that is not technical. Read on.
> This is not quite true. Dragonfly's vaunted resistance to offline
> attack doesn't hold
> in the standard model or the ROM because there are some hash functions
> (like hashing+exponentiation)
> which break it. This is a very serious issue: it means we don't know
> what it means for Dragonfly to be secure.

  "vaunted"? The fact that you have to exaggerate reveals much.

  If "it looks good to me" is not enough for you then certainly
"it doesn't have a security proof" is not evidence of flaws and
susceptibility to attack.

  So instead of "that is not quite true", it actually is. Quite.

>>> Dear CFRG (cc: TLS, SAAG),
>>>
>>> I'd like to understand how the CFRG decides on guidance to provide IETF
>>> WGs.
>>>
>>> It appears the CFRG chairs provide this guidance based on their own
>>> opinions, disregarding any feedback from the mailing list or IETF
>>> meetings.
>>>
>>> In particular, the CFRG chairs have repeatedly endorsed the
>>> "Dragonfly" protocol to the TLS WG.  However, I find no evidence of
>>> *ANY* positive feedback regarding Dragonfly in the CFRG mailing list
>>> or meeting minutes, except from the draft's author and CFRG co-chair
>>> Kevin Igoe.
>>>
>>> Compared to Kevin's enthusiasm, note:
>>>  * Respected cryptographers and security engineers like Jonathan Katz,
>>> Adam Back, and Rene Struik expressed skepticism on the list
>>
>>   Let's look at those, read on.
>>
>>>  * The single in-depth discussion at an IETF meeting was a string of
>>> complaints
>>
>>   That's what comments are. And they get addressed.
>>
>>>  * Alternative proposals were made to CFRG (J-PAKE, AugPAKE).
>>>
>>> Could the chairs please clarify how they decided to endorse Dragonfly
>>> to
>>> TLS WG?
>>>
>>>
>>> Below is a summary of all CFRG discussion of Dragonfly.
>>>
>>> =====
>>>
>>> Feb 2008
>>>  - Dan Harkins proposes early Dragonfly to CFRG
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg02205.html
>>>
>>>  - Scott Fluhrer breaks it
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg02206.html
>>
>>   An event mentioned in the acknowledgments. Thank you Scott.
>> His review and comments have been most helpful.
>>
>>>
>>> Nov 2011
>>>  - David McGrew appoints Kevin Igoe as CFRG co-chair
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html
>>
>>   Completely and utterly irrelevant.
>>
>>> Dec 2011
>>>  - Dan Harkins asks CFRG to look at TLS-PWD, based on Dragonfly
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html
>>>
>>>  - Scott Fluhrer points out a problem
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03045.html
>>
>>   A simple "sanity" check that the an ECC point is not "infinity".
>> Again,
>> a good comment.
>>
>>>  - Adam Back questions necessity of it, and lack of security
>>>    analysis
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html
>>
>>   He does no such thing. He notices that SRP is not mentioned in the
>> draft. Quite true. And he asks what key exchange is being implemented
>> because "its harder than it looks". Which is also quite true.
>>
>>> Jan 2012
>>>  - Kevin Igoe's first email to CFRG:
>>>    "I really like this idea & can find no problems."
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html
>>>
>>>  - Jonathan Katz questions lack of security analysis, points out
>>>    problems
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html
>>
>>   Yes, helpful comments on the draft. The susceptibility to attack under
>> the random oracle model is, in fact, mentioned in my slide deck when
>> I presented to the CFRG in Paris at IETF 83. It is a highly contrived
>> scenario and completely unlikely a real world protocol but it does raise
>> the question of making a formal proof in that model.
> On the contrary: "it looks secure to me" is not an acceptable foundation
> for
> cryptographic protocols. I do not want any protocol I approve to be a
> CRYPTO
> keynote in the future.

  Cryptographic protocols that you approve? Since when are you the
gatekeeper? What cryptographic protocols have you approved of?

  Here's an idea: find an attack on dragonfly and present it to CRYPTO
in the future. Something to pad your CV.

>>   You should link to my slide deck in your next broadside.
>>
>>> March 2012
>>>  - At IETF 83 CFRG meeting, concerns are raised about:
>>>    - SPEKE patents
>>>    - necessity of a new scheme
>>>    - timing attacks
>>>    - non-augmented properties
>>>  http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt
>>
>>   Wow, you make it sound as if you were there. But you weren't. And
>> your summary is not an accurate description of the meeting. The
>> sole mention in the minutes of SPEKE is from me. And the "concerns"
>> are a recitation of comments received. That's how it works. You get
>> comments and you resolve them.
>>
>>> May 2012
>>>  - Kevin Igoe points out a limitation due to "hunting-and-pecking"
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html
>>
>>   He does no such thing. He just said that if the prime defining the
>> curve p = 3 mod 4 that it's easier to compute the square root.
>>
>>>  - Zhou Sujing and Dan have an exchange that's hard to follow.
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03115.html
>>>
>>> July 2012
>>>  - At IETF 84 TLS meeting (CFRG does not meet):
>>>    - Kevin Igoe informs TLS WG, as the CFRG chair:
>>>      "We approve of it, very clear and usable for general setting."
>>>  http://www.ietf.org/proceedings/84/minutes/minutes-84-tls
>>
>>   Also note the comment: "Tie Dragonfly into EST would be very useful"
>> Yes, it would.
>>
>>> Oct 2012
>>>  - Kevin Igoe calls CFRG attention to Dragonfly draft-00
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03214.html
>>>
>>>  - Jonathan Katz asks for a security proof - there is none
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03215.html
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html
>>
>>   Correct. There is no formal proof of security. See my slides from
>> IETF 83.
>>
>>> Dec 2012
>>>  - Kevin Igoe calls CFRG attention to Dragonfly
>>>    - raises timing attack issue, proposes 2 fixes, including
>>>      rediscovery of Dan's original broken method (2008)
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html
>>
>>   This is further discussion on addressing a side channel attack.
>> Your attempt to spin this as "broken" is somewhat desperate.
> Modern cryptographic practice demands constant time, jump-free,
> no variable memory access cryptography.
>>
>>>  - Rene Struik points out the error in Kevin's proposal, and
>>>    the inefficiency of Dragonfly relative to SPEKE
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html
>>
>>   He does no such thing. His "Suppose A and B…" is a recitation of
>> a version of SPEKE that does not hash the password into a group in
>> the domain parameter set. It's neither here nor there with respect
>> to dragonfly. He further goes on to suggest on a check for "point at
>> infinity". Which is already part of dragonfly.
>>
>>   There is no "error" noted and no "inefficiency" mentioned either.
>>
>>>  - Scott Fluhrer points out the error in Kevin's proposal, and
>>>    proposes a flawed "mostly constant time" fix.  Dan and Kevin
>>>    embrace it.
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03260.html
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03263.html
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03265.html
>>
>>   As noted in the email thread, the described fix was added to the
>> draft at the time. Your opinion on it being "flawed" has already been
>> noted.
>>
>>> Feb 2013
>>>  - draft-01 is uploaded with flawed sidechannel fix
>>>    - also quietly fixes security issue reported by Dylan Clarke
>>>      and Feng Hao
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03309.html
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03529.html
>>
>>   This is a small sub-group attack possible if one does not check
>> validity of received elements. All incarnations of dragonfly-- TLS-PWD,
>> EAP-PWD and 802.11 already did this. It is entirely my fault that I left
>> that
>> crucial step out of the -00 version of the CFRG draft but it is hardly
>> a flaw.
>>
>>> Apr 2013
>>>  - Kevin Igoe mentions a last call for Dragonfly
>>>    "The design looks mature, it addresses a real need, and no one
>>>     has raised any issues."
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html
>>
>>   That's correct. You are included in that "no one".
>>
>>> May 2013
>>>  - Feng Hao asks CFRG to consider J-PAKE (an alternative)
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html
>>
>>   Completely irrelevant.
>>
> I don't think so. Your repeated insistence to the contrary, there are
> people who
> will use RC4 on TLS connections, etc, etc. Our endorsing a protocol
> when superior
> alternatives exist is a bad thing, because insecure options have a
> nasty habit of being
> turned on. You've argued that because you and your employer don't see
> an issue, we should
> be happy to endorse this.

  RC4? What the hell does that have to do with anything?

  And when did I insist that people will not use RC4? And when did I
mention my employer? Never and never.

  You are obviously very confused.

>>> July 2013
>>>  - Rene Struik points out spec bugs, raises timing attack issue
>>>    again
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03486.html
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html
>>
>>   "Spec bugs", in other words typos. Yes, he brings up an issue that
>> had previously been addressed.
>>
>>>  - IETF 87, CFRG meeting:
>>>    - "The author is working on a new (and hopefully final) draft"
>>>  http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg
>>
>>   Sadly, it's not. I have to address the "Spec bugs" and address
>> Rene's other comments, none of which demonstrate security flaws.
>>
>>> Aug 2013
>>>  - draft-02 is uploaded with modifications to "hunting-and-pecking"
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html
>>
>>   Don't forget comments dealing with internationalization!
>>
>>   The change is from a comment received from, if I recall, Russ Housley
>> to use the technique from FIPS 186-3 to hide the bias added by the
>> modular reduction. Again, a very nice comment, happily accepted.
> Knuth discusses this in detail in Volume 2. Bleichenbacher got a lot
> of mileage from
> this.

  So? Aside from giving you an opportunity to name drop, what does
that have to do with anything? The comment was made, it was not
asserted as being some original insight, and it was accepted.

>>> Sep 2013
>>>  - SeongHan Shin asks CFRG to consider AugPAKE (an alternative)
>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html
>>
>>   Completely irrelevant. (Again, not sure why you're have become such
>> a cheerleader for AugPAKE).
>>
>>> Nov/Dec 2013
>>>  - Joe Saloway begins TLS-PWD last call, and informs TLS WG that:
>>>    "The underlying cryptographic protocol for TLS-PWD has been
>>>    reviewed by the IRTF CFRG group with satisfactory results."
>>>  http://www.ietf.org/mail-archive/web/tls/current/msg10476.html
>>>
>>>  - Uproar on TLS WG:
>>>
>>>    - Many object to lack of formal security analysis:
>>>      Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik,
>>>      Watson Ladd
>>
>>   Missing, of course, the caveat "-- except I believe that whenever
>> possible the IETF should aim to standardize cryptographic protocols
>> that are unencumbered by license fees and patents. If the choice
>> arises between a protocol that carries both (provable security and
>> Intellectual Property) and a protocol that has neither - I'd strongly
>> prefer the latter."
>>
>>>    - Many point out better alternatives:
>>>      SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin
>>
>>   And you're all free to write up Internet Drafts on them too!
> Why do you want Dragonfly as opposed to J-PAKE? If you think it is
> going to slow, call up Feng Hao and offer to help. That would satisfy the
> need you identify in your usecase in the TLS WG.
> Or is this not about solving the problem of password authenticated key
> exchange,
> but putting your protocol into things?

  Why don't you do a draft on J-PAKE? I asked you before to please write
an Internet Draft. Please. I would really appreciate the opportunity to
review such a document. Why don't you offer to help Feng Hao?

  What this has to do with is a desire to have a TLS cipher suite to
satisfy legitimate use cases yesterday. You come along 2+ years late
and then say that it should all be abandoned and something else pursued.
Because _you_ don't approve. Your suggestions might've been helpful
2+ years ago, now they're just a delaying tactic.

>>   In fact, SeongHan Shin has been following me around EMU, IPsec,
>> CFRG and now TLS doing just that. After I write a dragonfly I-D he
>> writes an AugPAKE I-D. Nothing is stopping you from doing it too.
>>
>>>    - Security flaws are pointed out by Bodo Moeller and
>>>      CodesInChaos
>>>    http://www.ietf.org/mail-archive/web/tls/current/msg10708.html
>>>    http://www.ietf.org/mail-archive/web/tls/current/msg10768.html
>>
>>   Bodo's comment has been addressed. I dispute the use of the term
>> "security flaw" to describe it but that is consistent with the rest of
>> your email.
>>
>>   CodesInChaos suggested using PBKDF2 to hash the password. This
>> really provides no additional benefit,, as I noted in a subsequent
>> email (see coWPAtty and family attacks against a protocol that uses
>> PBKDF2).
>>
>>>    - Rene Struik and Bodo Moeller dispute that CFRG approved this
>>>    http://www.ietf.org/mail-archive/web/tls/current/msg10769.html
>>>
>>>    http://www.ietf.org/mail-archive/web/tls/current/msg10812.html
>>
>>   Actually, Rene notes that CFRG has not issued a LC. He does raise
>> some comments, many of which are already addressed in the draft
>> and he points out the "Spec bug" you allude to earlier. He suggests
>> relaxation of one of the restrictions on parameter generation that I
>> decline to accept. And he finds some additional typos and an
>> erroneous description of point addition. Helpful comments.
>>
>>>  - Eric Rescorla (TLS WG chair) states:
>>>    "we did have a verbal report back from the chair of the CFRG
>>>    that they considered it satisfactory"
>>>  http://www.ietf.org/mail-archive/web/tls/current/msg10819.html
>>
>>   Indeed.
>>
>>   So what you've brought up is that there has been discussion of
>> dragonfly on the list and it has, in fact, been reviewed. Quite a few
>> comments have been made and resolved, security critical issues have
>> been raised and properly addressed.
> Sorry, but review is not enough. Approval is. What standard is the
> chair applying here?

  The existing standard that is in place for TLS and the IETF.

>>   There are no flaws in the key exchange. It has some aspects to it
>> that some may feel is a benefit and some may feel is a detriment.
>> Personal taste is not something that can be universally accommodated.
>>
>>   Nothing you have raised here is reason to stop advancement of
>> this draft.
> I disagree. This draft is reminiscent of the worst of 90's
> cryptography: ad-hoc assumptions,
> no formal statement of security, gratuitously not a circuit, and not
> subject by review by anyone
> who is a cryptographer. It may be that this draft has exposed a fault
> line between those who think
> the current process is acceptable and those who do not.

  It lacks a formal security proof. That is all. There is no other problem
with it. The side channel attack issue was already addressed after a
long thread a long time ago. One might consider revisiting it if the
people harping about it really wanted a change, instead of just using
it as a box on which to stand so as to shout more loudly.

  Lacking any valid issue with dragonfly I suggest you go back to
obsessing over RC4.

  Dan.



From watsonbladd@gmail.com  Fri Dec 13 00:00:44 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64521AE6AA; Fri, 13 Dec 2013 00:00:44 -0800 (PST)
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 gHiLxpROKsk2; Fri, 13 Dec 2013 00:00:30 -0800 (PST)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBAC1AE203; Fri, 13 Dec 2013 00:00:29 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id q58so1507490wes.2 for ; Fri, 13 Dec 2013 00:00:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=odnGFYfUOrcEYwuGJxbwEe8rm6/XfjbZNiZoasfMGik=; b=I61fcvDDCwC2XQklslxTIB1sdQghhsooqB/RiigdZUNx7acbV7y/j0m4rExRMMIohm HMR7WKjCToqLUyYMVbv6+aTLdcNVmKSwW2xdIPMz3htf5Io4j5/cw5WqKX3IVtlB9/gN mLmSuw2wUVjPzlYlpyk/QqeDJeZ//GY5iPJHWtfY2ndLjvjlTffV45jbrsTTZ8KjwQTr lCTErv0SayXpIRuWjbnazkt8lSkBbxMgmwvQkDG5nuip0ZYU70R5uB40+nZDLzDgwO3M 9B4NCCPkbltbvqmy5DukePIHI1edvbfrD4Msj62AKGZ95kKcOCFXUwTjI40AySDRh3GW j0iw==
MIME-Version: 1.0
X-Received: by 10.180.73.6 with SMTP id h6mr1314576wiv.20.1386921622139; Fri, 13 Dec 2013 00:00:22 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Fri, 13 Dec 2013 00:00:22 -0800 (PST)
In-Reply-To: 
References:  <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net>  
Date: Fri, 13 Dec 2013 00:00:22 -0800
Message-ID: 
From: Watson Ladd 
To: Dan Harkins 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org
Subject: Re: [TLS] [saag] Question regarding CFRG process
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 08:00:44 -0000

On Thu, Dec 12, 2013 at 11:15 PM, Dan Harkins  wrote:
>
> On Thu, December 12, 2013 7:36 pm, Watson Ladd wrote:
>> On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins  wrote=
:
>>>
>>> On Thu, December 12, 2013 4:06 pm, Trevor Perrin wrote:
>>>
>>>   ...an extremely misleading email.
>>>
>>>   Using pejoratives like "bug", "flaw", and "attack" he attempts a
>>> smear of people, a protocol, and process. In reality there is no
>>> security bug or flaw or attack with dragonfly.
>>>
>>>   There is obviously some personal animosity and taste involved
>>> but that is not technical. Read on.
>> This is not quite true. Dragonfly's vaunted resistance to offline
>> attack doesn't hold
>> in the standard model or the ROM because there are some hash functions
>> (like hashing+exponentiation)
>> which break it. This is a very serious issue: it means we don't know
>> what it means for Dragonfly to be secure.
>
>   "vaunted"? The fact that you have to exaggerate reveals much.
>
>   If "it looks good to me" is not enough for you then certainly
> "it doesn't have a security proof" is not evidence of flaws and
> susceptibility to attack.

The consequences of adopting a protocol we think is secure that
isn't: dead people.

The consequences of ruling out a protocol that is secure because we
think it isn't: In this case nothing as the usecase is already handled.

Are you seriously arguing that Dragonfly's security is independent of ZF?

>
>   So instead of "that is not quite true", it actually is. Quite.
>
>>>> Dear CFRG (cc: TLS, SAAG),
>>>>
>>>> I'd like to understand how the CFRG decides on guidance to provide IET=
F
>>>> WGs.
>>>>
>>>> It appears the CFRG chairs provide this guidance based on their own
>>>> opinions, disregarding any feedback from the mailing list or IETF
>>>> meetings.
>>>>
>>>> In particular, the CFRG chairs have repeatedly endorsed the
>>>> "Dragonfly" protocol to the TLS WG.  However, I find no evidence of
>>>> *ANY* positive feedback regarding Dragonfly in the CFRG mailing list
>>>> or meeting minutes, except from the draft's author and CFRG co-chair
>>>> Kevin Igoe.
>>>>
>>>> Compared to Kevin's enthusiasm, note:
>>>>  * Respected cryptographers and security engineers like Jonathan Katz,
>>>> Adam Back, and Rene Struik expressed skepticism on the list
>>>
>>>   Let's look at those, read on.
>>>
>>>>  * The single in-depth discussion at an IETF meeting was a string of
>>>> complaints
>>>
>>>   That's what comments are. And they get addressed.
>>>
>>>>  * Alternative proposals were made to CFRG (J-PAKE, AugPAKE).
>>>>
>>>> Could the chairs please clarify how they decided to endorse Dragonfly
>>>> to
>>>> TLS WG?
>>>>
>>>>
>>>> Below is a summary of all CFRG discussion of Dragonfly.
>>>>
>>>> =3D=3D=3D=3D=3D
>>>>
>>>> Feb 2008
>>>>  - Dan Harkins proposes early Dragonfly to CFRG
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg02205.html
>>>>
>>>>  - Scott Fluhrer breaks it
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg02206.html
>>>
>>>   An event mentioned in the acknowledgments. Thank you Scott.
>>> His review and comments have been most helpful.
>>>
>>>>
>>>> Nov 2011
>>>>  - David McGrew appoints Kevin Igoe as CFRG co-chair
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html
>>>
>>>   Completely and utterly irrelevant.
>>>
>>>> Dec 2011
>>>>  - Dan Harkins asks CFRG to look at TLS-PWD, based on Dragonfly
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html
>>>>
>>>>  - Scott Fluhrer points out a problem
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03045.html
>>>
>>>   A simple "sanity" check that the an ECC point is not "infinity".
>>> Again,
>>> a good comment.
>>>
>>>>  - Adam Back questions necessity of it, and lack of security
>>>>    analysis
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html
>>>
>>>   He does no such thing. He notices that SRP is not mentioned in the
>>> draft. Quite true. And he asks what key exchange is being implemented
>>> because "its harder than it looks". Which is also quite true.
>>>
>>>> Jan 2012
>>>>  - Kevin Igoe's first email to CFRG:
>>>>    "I really like this idea & can find no problems."
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html
>>>>
>>>>  - Jonathan Katz questions lack of security analysis, points out
>>>>    problems
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html
>>>
>>>   Yes, helpful comments on the draft. The susceptibility to attack unde=
r
>>> the random oracle model is, in fact, mentioned in my slide deck when
>>> I presented to the CFRG in Paris at IETF 83. It is a highly contrived
>>> scenario and completely unlikely a real world protocol but it does rais=
e
>>> the question of making a formal proof in that model.
>> On the contrary: "it looks secure to me" is not an acceptable foundation
>> for
>> cryptographic protocols. I do not want any protocol I approve to be a
>> CRYPTO
>> keynote in the future.
>
>   Cryptographic protocols that you approve? Since when are you the
> gatekeeper? What cryptographic protocols have you approved of?

I'm not the gatekeeper, merely someone with the training required to do
cryptography. By all accounts such a person hasn't been on the TLS WG
in a long time.

>
>   Here's an idea: find an attack on dragonfly and present it to CRYPTO
> in the future. Something to pad your CV.
>
>>>   You should link to my slide deck in your next broadside.
>>>
>>>> March 2012
>>>>  - At IETF 83 CFRG meeting, concerns are raised about:
>>>>    - SPEKE patents
>>>>    - necessity of a new scheme
>>>>    - timing attacks
>>>>    - non-augmented properties
>>>>  http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt
>>>
>>>   Wow, you make it sound as if you were there. But you weren't. And
>>> your summary is not an accurate description of the meeting. The
>>> sole mention in the minutes of SPEKE is from me. And the "concerns"
>>> are a recitation of comments received. That's how it works. You get
>>> comments and you resolve them.
>>>
>>>> May 2012
>>>>  - Kevin Igoe points out a limitation due to "hunting-and-pecking"
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html
>>>
>>>   He does no such thing. He just said that if the prime defining the
>>> curve p =3D 3 mod 4 that it's easier to compute the square root.
>>>
>>>>  - Zhou Sujing and Dan have an exchange that's hard to follow.
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03115.html
>>>>
>>>> July 2012
>>>>  - At IETF 84 TLS meeting (CFRG does not meet):
>>>>    - Kevin Igoe informs TLS WG, as the CFRG chair:
>>>>      "We approve of it, very clear and usable for general setting."
>>>>  http://www.ietf.org/proceedings/84/minutes/minutes-84-tls
>>>
>>>   Also note the comment: "Tie Dragonfly into EST would be very useful"
>>> Yes, it would.
>>>
>>>> Oct 2012
>>>>  - Kevin Igoe calls CFRG attention to Dragonfly draft-00
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03214.html
>>>>
>>>>  - Jonathan Katz asks for a security proof - there is none
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03215.html
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html
>>>
>>>   Correct. There is no formal proof of security. See my slides from
>>> IETF 83.
>>>
>>>> Dec 2012
>>>>  - Kevin Igoe calls CFRG attention to Dragonfly
>>>>    - raises timing attack issue, proposes 2 fixes, including
>>>>      rediscovery of Dan's original broken method (2008)
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html
>>>
>>>   This is further discussion on addressing a side channel attack.
>>> Your attempt to spin this as "broken" is somewhat desperate.
>> Modern cryptographic practice demands constant time, jump-free,
>> no variable memory access cryptography.
>>>
>>>>  - Rene Struik points out the error in Kevin's proposal, and
>>>>    the inefficiency of Dragonfly relative to SPEKE
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html
>>>
>>>   He does no such thing. His "Suppose A and B=E2=80=A6" is a recitation=
 of
>>> a version of SPEKE that does not hash the password into a group in
>>> the domain parameter set. It's neither here nor there with respect
>>> to dragonfly. He further goes on to suggest on a check for "point at
>>> infinity". Which is already part of dragonfly.
>>>
>>>   There is no "error" noted and no "inefficiency" mentioned either.
>>>
>>>>  - Scott Fluhrer points out the error in Kevin's proposal, and
>>>>    proposes a flawed "mostly constant time" fix.  Dan and Kevin
>>>>    embrace it.
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03260.html
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03263.html
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03265.html
>>>
>>>   As noted in the email thread, the described fix was added to the
>>> draft at the time. Your opinion on it being "flawed" has already been
>>> noted.
>>>
>>>> Feb 2013
>>>>  - draft-01 is uploaded with flawed sidechannel fix
>>>>    - also quietly fixes security issue reported by Dylan Clarke
>>>>      and Feng Hao
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03309.html
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03529.html
>>>
>>>   This is a small sub-group attack possible if one does not check
>>> validity of received elements. All incarnations of dragonfly-- TLS-PWD,
>>> EAP-PWD and 802.11 already did this. It is entirely my fault that I lef=
t
>>> that
>>> crucial step out of the -00 version of the CFRG draft but it is hardly
>>> a flaw.
>>>
>>>> Apr 2013
>>>>  - Kevin Igoe mentions a last call for Dragonfly
>>>>    "The design looks mature, it addresses a real need, and no one
>>>>     has raised any issues."
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html
>>>
>>>   That's correct. You are included in that "no one".
>>>
>>>> May 2013
>>>>  - Feng Hao asks CFRG to consider J-PAKE (an alternative)
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html
>>>
>>>   Completely irrelevant.
>>>
>> I don't think so. Your repeated insistence to the contrary, there are
>> people who
>> will use RC4 on TLS connections, etc, etc. Our endorsing a protocol
>> when superior
>> alternatives exist is a bad thing, because insecure options have a
>> nasty habit of being
>> turned on. You've argued that because you and your employer don't see
>> an issue, we should
>> be happy to endorse this.
>
>   RC4? What the hell does that have to do with anything?
>
>   And when did I insist that people will not use RC4? And when did I
> mention my employer? Never and never.
>
>   You are obviously very confused.

Your argument seems to be that even if dragonfly is later discovered insecu=
re,
or we don't want to use it, it will be fine because people will configure
their systems appropriately. Our experience shows that is not the case.

I have a much more cynical view: systems are only fixed when broken, and
not even then. We are the sole line between a bunch of idiots and the NSA.

>
>>>> July 2013
>>>>  - Rene Struik points out spec bugs, raises timing attack issue
>>>>    again
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03486.html
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html
>>>
>>>   "Spec bugs", in other words typos. Yes, he brings up an issue that
>>> had previously been addressed.
>>>
>>>>  - IETF 87, CFRG meeting:
>>>>    - "The author is working on a new (and hopefully final) draft"
>>>>  http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg
>>>
>>>   Sadly, it's not. I have to address the "Spec bugs" and address
>>> Rene's other comments, none of which demonstrate security flaws.
>>>
>>>> Aug 2013
>>>>  - draft-02 is uploaded with modifications to "hunting-and-pecking"
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html
>>>
>>>   Don't forget comments dealing with internationalization!
>>>
>>>   The change is from a comment received from, if I recall, Russ Housley
>>> to use the technique from FIPS 186-3 to hide the bias added by the
>>> modular reduction. Again, a very nice comment, happily accepted.
>> Knuth discusses this in detail in Volume 2. Bleichenbacher got a lot
>> of mileage from
>> this.
>
>   So? Aside from giving you an opportunity to name drop, what does
> that have to do with anything? The comment was made, it was not
> asserted as being some original insight, and it was accepted.
>
>>>> Sep 2013
>>>>  - SeongHan Shin asks CFRG to consider AugPAKE (an alternative)
>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html
>>>
>>>   Completely irrelevant. (Again, not sure why you're have become such
>>> a cheerleader for AugPAKE).
>>>
>>>> Nov/Dec 2013
>>>>  - Joe Saloway begins TLS-PWD last call, and informs TLS WG that:
>>>>    "The underlying cryptographic protocol for TLS-PWD has been
>>>>    reviewed by the IRTF CFRG group with satisfactory results."
>>>>  http://www.ietf.org/mail-archive/web/tls/current/msg10476.html
>>>>
>>>>  - Uproar on TLS WG:
>>>>
>>>>    - Many object to lack of formal security analysis:
>>>>      Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik,
>>>>      Watson Ladd
>>>
>>>   Missing, of course, the caveat "-- except I believe that whenever
>>> possible the IETF should aim to standardize cryptographic protocols
>>> that are unencumbered by license fees and patents. If the choice
>>> arises between a protocol that carries both (provable security and
>>> Intellectual Property) and a protocol that has neither - I'd strongly
>>> prefer the latter."
>>>
>>>>    - Many point out better alternatives:
>>>>      SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin
>>>
>>>   And you're all free to write up Internet Drafts on them too!
>> Why do you want Dragonfly as opposed to J-PAKE? If you think it is
>> going to slow, call up Feng Hao and offer to help. That would satisfy th=
e
>> need you identify in your usecase in the TLS WG.
>> Or is this not about solving the problem of password authenticated key
>> exchange,
>> but putting your protocol into things?
>
>   Why don't you do a draft on J-PAKE? I asked you before to please write
> an Internet Draft. Please. I would really appreciate the opportunity to
> review such a document. Why don't you offer to help Feng Hao?

He already wrote a such a draft. I'm not the right person to bri^H^H^H lobb=
y
the WG chairs to get this through, because I don't have thousands of dollar=
s of
other people's money to spend on junkets in Honolulu. I also don't have a n=
eed
for a PAKE: TOFU with certificates works well enough for my usecases. But f=
or
embedded devices I see the utility.

>
>   What this has to do with is a desire to have a TLS cipher suite to
> satisfy legitimate use cases yesterday. You come along 2+ years late
> and then say that it should all be abandoned and something else pursued.
> Because _you_ don't approve. Your suggestions might've been helpful
> 2+ years ago, now they're just a delaying tactic.

SRP satisfies this use case and was available then. J-PAKE was 3 years
old then. The Socialist Millionaire's Protocol was 5 years old.

>
>>>   In fact, SeongHan Shin has been following me around EMU, IPsec,
>>> CFRG and now TLS doing just that. After I write a dragonfly I-D he
>>> writes an AugPAKE I-D. Nothing is stopping you from doing it too.
>>>
>>>>    - Security flaws are pointed out by Bodo Moeller and
>>>>      CodesInChaos
>>>>    http://www.ietf.org/mail-archive/web/tls/current/msg10708.html
>>>>    http://www.ietf.org/mail-archive/web/tls/current/msg10768.html
>>>
>>>   Bodo's comment has been addressed. I dispute the use of the term
>>> "security flaw" to describe it but that is consistent with the rest of
>>> your email.
>>>
>>>   CodesInChaos suggested using PBKDF2 to hash the password. This
>>> really provides no additional benefit,, as I noted in a subsequent
>>> email (see coWPAtty and family attacks against a protocol that uses
>>> PBKDF2).
>>>
>>>>    - Rene Struik and Bodo Moeller dispute that CFRG approved this
>>>>    http://www.ietf.org/mail-archive/web/tls/current/msg10769.html
>>>>
>>>>    http://www.ietf.org/mail-archive/web/tls/current/msg10812.html
>>>
>>>   Actually, Rene notes that CFRG has not issued a LC. He does raise
>>> some comments, many of which are already addressed in the draft
>>> and he points out the "Spec bug" you allude to earlier. He suggests
>>> relaxation of one of the restrictions on parameter generation that I
>>> decline to accept. And he finds some additional typos and an
>>> erroneous description of point addition. Helpful comments.
>>>
>>>>  - Eric Rescorla (TLS WG chair) states:
>>>>    "we did have a verbal report back from the chair of the CFRG
>>>>    that they considered it satisfactory"
>>>>  http://www.ietf.org/mail-archive/web/tls/current/msg10819.html
>>>
>>>   Indeed.
>>>
>>>   So what you've brought up is that there has been discussion of
>>> dragonfly on the list and it has, in fact, been reviewed. Quite a few
>>> comments have been made and resolved, security critical issues have
>>> been raised and properly addressed.
>> Sorry, but review is not enough. Approval is. What standard is the
>> chair applying here?
>
>   The existing standard that is in place for TLS and the IETF.

I don't think you noticed that this standard produced IPSEC with
encrypt only, IKE1,
TLS bugs galore, and many other issues. As I mention below, this seems to b=
e the
real difference: you are the first person who ran into the tougher
standards many of
us think are warranted.

>
>>>   There are no flaws in the key exchange. It has some aspects to it
>>> that some may feel is a benefit and some may feel is a detriment.
>>> Personal taste is not something that can be universally accommodated.
>>>
>>>   Nothing you have raised here is reason to stop advancement of
>>> this draft.
>> I disagree. This draft is reminiscent of the worst of 90's
>> cryptography: ad-hoc assumptions,
>> no formal statement of security, gratuitously not a circuit, and not
>> subject by review by anyone
>> who is a cryptographer. It may be that this draft has exposed a fault
>> line between those who think
>> the current process is acceptable and those who do not.
>
>   It lacks a formal security proof. That is all. There is no other proble=
m
> with it. The side channel attack issue was already addressed after a
> long thread a long time ago. One might consider revisiting it if the
> people harping about it really wanted a change, instead of just using
> it as a box on which to stand so as to shout more loudly.

Could you please define what you mean by secure? I've been trying for
the past week to come up with a formal definition for the security of
dragonfly, and
not one of them has been any good.

>
>   Lacking any valid issue with dragonfly I suggest you go back to
> obsessing over RC4.

If RC4 was the only cryptography mistake the TLS WG made, life would be nic=
e.

>
>   Dan.
>
>
Sincerely,
Watson Ladd


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

From dharkins@lounge.org  Fri Dec 13 00:36:06 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D54E1AE6C3; Fri, 13 Dec 2013 00:36:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 VDtH6cvOdz-d; Fri, 13 Dec 2013 00:36:02 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD001AE6C5; Fri, 13 Dec 2013 00:36:02 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D013610224008; Fri, 13 Dec 2013 00:35:55 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 13 Dec 2013 00:35:56 -0800 (PST)
Message-ID: <8cf8a51b9dcfd0c40b80ae2aad2cff7c.squirrel@www.trepanning.net>
In-Reply-To: 
References:  <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net>   
Date: Fri, 13 Dec 2013 00:35:56 -0800 (PST)
From: "Dan Harkins" 
To: "Watson Ladd" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org
Subject: Re: [TLS] [saag] Question regarding CFRG process
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 08:36:06 -0000

On Fri, December 13, 2013 12:00 am, Watson Ladd wrote:
> On Thu, Dec 12, 2013 at 11:15 PM, Dan Harkins  wrote:
>>
>> On Thu, December 12, 2013 7:36 pm, Watson Ladd wrote:
>>> On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins 
>>> wrote:
>>>>
>>>> On Thu, December 12, 2013 4:06 pm, Trevor Perrin wrote:
>>>>
>>>>   ...an extremely misleading email.
>>>>
>>>>   Using pejoratives like "bug", "flaw", and "attack" he attempts a
>>>> smear of people, a protocol, and process. In reality there is no
>>>> security bug or flaw or attack with dragonfly.
>>>>
>>>>   There is obviously some personal animosity and taste involved
>>>> but that is not technical. Read on.
>>> This is not quite true. Dragonfly's vaunted resistance to offline
>>> attack doesn't hold
>>> in the standard model or the ROM because there are some hash functions
>>> (like hashing+exponentiation)
>>> which break it. This is a very serious issue: it means we don't know
>>> what it means for Dragonfly to be secure.
>>
>>   "vaunted"? The fact that you have to exaggerate reveals much.
>>
>>   If "it looks good to me" is not enough for you then certainly
>> "it doesn't have a security proof" is not evidence of flaws and
>> susceptibility to attack.
>
> The consequences of adopting a protocol we think is secure that
> isn't: dead people.
>
> The consequences of ruling out a protocol that is secure because we
> think it isn't: In this case nothing as the usecase is already handled.
>
> Are you seriously arguing that Dragonfly's security is independent of ZF?

  You obviously read too much fiction and have too little practical
experience. Dragonfly is not a threat to human life. Get a grip.

>>
>>   So instead of "that is not quite true", it actually is. Quite.
>>
[snip]
>>>>   Yes, helpful comments on the draft. The susceptibility to attack
>>>> under
>>>> the random oracle model is, in fact, mentioned in my slide deck when
>>>> I presented to the CFRG in Paris at IETF 83. It is a highly contrived
>>>> scenario and completely unlikely a real world protocol but it does
>>>> raise
>>>> the question of making a formal proof in that model.
>>> On the contrary: "it looks secure to me" is not an acceptable
>>> foundation
>>> for
>>> cryptographic protocols. I do not want any protocol I approve to be a
>>> CRYPTO
>>> keynote in the future.
>>
>>   Cryptographic protocols that you approve? Since when are you the
>> gatekeeper? What cryptographic protocols have you approved of?
>
> I'm not the gatekeeper, merely someone with the training required to do
> cryptography. By all accounts such a person hasn't been on the TLS WG
> in a long time.

  Yet you're not; you're just bloviating.

>>
>>   Here's an idea: find an attack on dragonfly and present it to CRYPTO
>> in the future. Something to pad your CV.
>>
[snip]
>>>>> May 2013
>>>>>  - Feng Hao asks CFRG to consider J-PAKE (an alternative)
>>>>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html
>>>>
>>>>   Completely irrelevant.
>>>>
>>> I don't think so. Your repeated insistence to the contrary, there are
>>> people who
>>> will use RC4 on TLS connections, etc, etc. Our endorsing a protocol
>>> when superior
>>> alternatives exist is a bad thing, because insecure options have a
>>> nasty habit of being
>>> turned on. You've argued that because you and your employer don't see
>>> an issue, we should
>>> be happy to endorse this.
>>
>>   RC4? What the hell does that have to do with anything?
>>
>>   And when did I insist that people will not use RC4? And when did I
>> mention my employer? Never and never.
>>
>>   You are obviously very confused.
>
> Your argument seems to be that even if dragonfly is later discovered
> insecure,
> or we don't want to use it, it will be fine because people will configure
> their systems appropriately. Our experience shows that is not the case.
>
> I have a much more cynical view: systems are only fixed when broken, and
> not even then. We are the sole line between a bunch of idiots and the NSA.

  Uhm, no. My _statement_ was that I never said anything about RC4
or how often, or not, if ever, RC4 is used. Nor did I mention my employer.

  You spun this entire thing out of thin air.

  Or, possibly, you have confused me with someone else.

>>
[snip]
>>   Why don't you do a draft on J-PAKE? I asked you before to please write
>> an Internet Draft. Please. I would really appreciate the opportunity to
>> review such a document. Why don't you offer to help Feng Hao?
>
> He already wrote a such a draft. I'm not the right person to bri^H^H^H
> lobby
> the WG chairs to get this through, because I don't have thousands of
> dollars of
> other people's money to spend on junkets in Honolulu. I also don't have a
> need
> for a PAKE: TOFU with certificates works well enough for my usecases. But
> for
> embedded devices I see the utility.

  Your ignorance of IETF process has been well demonstrated.

>>
>>   What this has to do with is a desire to have a TLS cipher suite to
>> satisfy legitimate use cases yesterday. You come along 2+ years late
>> and then say that it should all be abandoned and something else pursued.
>> Because _you_ don't approve. Your suggestions might've been helpful
>> 2+ years ago, now they're just a delaying tactic.
>
> SRP satisfies this use case and was available then. J-PAKE was 3 years
> old then. The Socialist Millionaire's Protocol was 5 years old.

  No, it doesn't. TLS-SRP does not support ECC and it is an augmented
PAKE scheme. And your suggestion now to use something else is, as
I have said, useless and 2+ years late.

>>
[snip]
>>>>>  - Eric Rescorla (TLS WG chair) states:
>>>>>    "we did have a verbal report back from the chair of the CFRG
>>>>>    that they considered it satisfactory"
>>>>>  http://www.ietf.org/mail-archive/web/tls/current/msg10819.html
>>>>
>>>>   Indeed.
>>>>
>>>>   So what you've brought up is that there has been discussion of
>>>> dragonfly on the list and it has, in fact, been reviewed. Quite a few
>>>> comments have been made and resolved, security critical issues have
>>>> been raised and properly addressed.
>>> Sorry, but review is not enough. Approval is. What standard is the
>>> chair applying here?
>>
>>   The existing standard that is in place for TLS and the IETF.
>
> I don't think you noticed that this standard produced IPSEC with
> encrypt only, IKE1,
> TLS bugs galore, and many other issues. As I mention below, this seems to
> be the
> real difference: you are the first person who ran into the tougher
> standards many of
> us think are warranted.

  I don't know what "IPSEC (sic) with encrypt only" is. But I am aware
of IKEv1. It's provably secure in its signature-mode of authentication.

  I'm also familiar with well-respected cryptographers who participated
in the IPsec WG in the 90s. You are nobody compared to them and your
ignorant reference confirms that.

>>>>   There are no flaws in the key exchange. It has some aspects to it
>>>> that some may feel is a benefit and some may feel is a detriment.
>>>> Personal taste is not something that can be universally accommodated.
>>>>
>>>>   Nothing you have raised here is reason to stop advancement of
>>>> this draft.
>>> I disagree. This draft is reminiscent of the worst of 90's
>>> cryptography: ad-hoc assumptions,
>>> no formal statement of security, gratuitously not a circuit, and not
>>> subject by review by anyone
>>> who is a cryptographer. It may be that this draft has exposed a fault
>>> line between those who think
>>> the current process is acceptable and those who do not.
>>
>>   It lacks a formal security proof. That is all. There is no other
>> problem
>> with it. The side channel attack issue was already addressed after a
>> long thread a long time ago. One might consider revisiting it if the
>> people harping about it really wanted a change, instead of just using
>> it as a box on which to stand so as to shout more loudly.
>
> Could you please define what you mean by secure? I've been trying for
> the past week to come up with a formal definition for the security of
> dragonfly, and
> not one of them has been any good.

  Try harder.

>>   Lacking any valid issue with dragonfly I suggest you go back to
>> obsessing over RC4.
>
> If RC4 was the only cryptography mistake the TLS WG made, life would be
> nice.

  And if you made useful contributions to TLS it would be nice.

  Dan.




From trevp@trevp.net  Fri Dec 13 02:29:36 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0541D1A8034 for ; Fri, 13 Dec 2013 02:29:36 -0800 (PST)
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=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 HsiYJOQYobqr for ; Fri, 13 Dec 2013 02:29:33 -0800 (PST)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 16F8B1AE1DC for ; Fri, 13 Dec 2013 02:29:27 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id y10so1685240wgg.12 for ; Fri, 13 Dec 2013 02:29:21 -0800 (PST)
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=xJtJNRyUzrpp+pYiY85WWJVK0advwfW3WSaKnEQU9hc=; b=egJ0VG1Eaf7rXpIpA7nxpuem2lTY4DIV3AIiFmi0fpv7i4aRxXA6G9Tn/iT1XnRIK3 OQQOXNL2MdjGlcC5R7GhFh7eNBtb4ENwlobn+PGlmBbuXR6VVhRHgNbJAuduVxrKyCWu ZN8kLCxb0X4WZ8Z1NMf0trMVKB5stmw9frI5oCXdvGvYkxROMSY5do7+aiu/UIAmGxwL W1fXmXqKfF+qvSbuEv6MobES0rwS3+1OoE/Vr6KYwq3FJtjJ1By+HjZQuHyfDFexR57s oxDeydzP6KDNDCfIABEIsndk8BF1DosH7jx0IYkBd1W5xHmdjkBjpnxK5es6LdS0SKoc JUQQ==
X-Gm-Message-State: ALoCoQnZKKWVZ7vWsVZ0GaQv/9JntqK0xQY6/STnN7XgsqvnVZhAC2xW1Akt0JM1Jx0Oitl/ZDgp
MIME-Version: 1.0
X-Received: by 10.180.94.164 with SMTP id dd4mr2313846wib.20.1386930561131; Fri, 13 Dec 2013 02:29:21 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Fri, 13 Dec 2013 02:29:21 -0800 (PST)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net>
References:  <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net>
Date: Fri, 13 Dec 2013 02:29:21 -0800
Message-ID: 
From: Trevor Perrin 
To: Dan Harkins 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org
Subject: Re: [TLS] [saag] Question regarding CFRG process
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 10:29:36 -0000

Dan, all,

My message was directed at the CFRG chairs.  I believe CFRG consensus
has been misrepresented regarding Dragonfly.

I'd appreciate if the chairs would respond to this.


Regarding Dan's objections to my summary, I attempt to set the record
straight below.

On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins  wrote:
>
>>
>> Below is a summary of all CFRG discussion of Dragonfly.
>>
>> =3D=3D=3D=3D=3D
>>
>> Feb 2008
>>  - Dan Harkins proposes early Dragonfly to CFRG
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg02205.html
>>
>>  - Scott Fluhrer breaks it
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg02206.html
>
>   An event mentioned in the acknowledgments. Thank you Scott.
> His review and comments have been most helpful.
>
>>
>> Nov 2011
>>  - David McGrew appoints Kevin Igoe as CFRG co-chair
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html
>
>   Completely and utterly irrelevant.
>
>> Dec 2011
>>  - Dan Harkins asks CFRG to look at TLS-PWD, based on Dragonfly
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html
>>
>>  - Scott Fluhrer points out a problem
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03045.html
>
>   A simple "sanity" check that the an ECC point is not "infinity". Again,
> a good comment.

A crucial security check!


>>  - Adam Back questions necessity of it, and lack of security
>>    analysis
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html
>
>   He does no such thing. He notices that SRP is not mentioned in the
> draft. Quite true. And he asks what key exchange is being implemented
> because "its harder than it looks". Which is also quite true.

I believe my description is accurate.


>> Jan 2012
>>  - Kevin Igoe's first email to CFRG:
>>    "I really like this idea & can find no problems."
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html
>>
>>  - Jonathan Katz questions lack of security analysis, points out
>>    problems
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html
>
>   Yes, helpful comments on the draft. The susceptibility to attack under
> the random oracle model is, in fact, mentioned in my slide deck when
> I presented to the CFRG in Paris at IETF 83. It is a highly contrived
> scenario and completely unlikely a real world protocol but it does raise
> the question of making a formal proof in that model.
>
>   You should link to my slide deck in your next broadside.

The random oracle model is a well-accepted methodology for analyzing
crypto protocols.

The SPEKE protocol, which Dragonfly is based on, has some degree of
formal security proof in the random oracle model.  If this proof does
not carry over to Dragonfly, that's a source of concern:

https://eprint.iacr.org/2001/057.pdf


>> March 2012
>>  - At IETF 83 CFRG meeting, concerns are raised about:
>>    - SPEKE patents
>>    - necessity of a new scheme
>>    - timing attacks
>>    - non-augmented properties
>>  http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt
>
>   Wow, you make it sound as if you were there. But you weren't. And
> your summary is not an accurate description of the meeting.

I wasn't there.  I believe my summary of the minutes is accurate.


> The
> sole mention in the minutes of SPEKE is from me.

"""
Yoav Nir - there are no IPR?  Really?  Is it really enough different
from speke that they won't go after.
"""


> And the "concerns"
> are a recitation of comments received. That's how it works. You get
> comments and you resolve them.

The "concerns" seem critical of the whole enterprise:
 - "there are no IPR?  Really?"
 - "Why the not use what IEEE already had defined in P1363"
 - "The difference between the scheme and SRP.  Here both
    sides need to have same secret."
 - "could you scheme be made to be like SRP."

This don't sound like CFRG approval.  Yet after no significant further
discussion, at IETF 84 the CFRG chair claims:

"""
Kevin Igoe: We approve of it, very clear and usable for general setting.
"""


>> May 2012
>>  - Kevin Igoe points out a limitation due to "hunting-and-pecking"
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html
>
>   He does no such thing. He just said that if the prime defining the
> curve p =3D 3 mod 4 that it's easier to compute the square root.

Kevin recommended constraining Dragonfly to elliptic curves over those fiel=
ds.

This would eliminate Curve25519, and probably some other curves.


>>  - Zhou Sujing and Dan have an exchange that's hard to follow.
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03115.html
>>
>> July 2012
>>  - At IETF 84 TLS meeting (CFRG does not meet):
>>    - Kevin Igoe informs TLS WG, as the CFRG chair:
>>      "We approve of it, very clear and usable for general setting."
>>  http://www.ietf.org/proceedings/84/minutes/minutes-84-tls
>
>   Also note the comment: "Tie Dragonfly into EST would be very useful"
> Yes, it would.

I appreciate that the CFRG chairs are fond of Dragonfly.

I'd like to understand where this approval comes from.


>> Oct 2012
>>  - Kevin Igoe calls CFRG attention to Dragonfly draft-00
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03214.html
>>
>>  - Jonathan Katz asks for a security proof - there is none
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03215.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html
>
>   Correct. There is no formal proof of security. See my slides from
> IETF 83.

I read Jonathan's re-iteration of this point as expressing concern.


>> Dec 2012
>>  - Kevin Igoe calls CFRG attention to Dragonfly
>>    - raises timing attack issue, proposes 2 fixes, including
>>      rediscovery of Dan's original broken method (2008)
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html
>
>   This is further discussion on addressing a side channel attack.
> Your attempt to spin this as "broken" is somewhat desperate.

Kevin's paragraph starting "A possible fix" is a rediscovery of the
older Dragonfly technique which Scott Fluhrer broke in 2008.


>>  - Rene Struik points out the error in Kevin's proposal, and
>>    the inefficiency of Dragonfly relative to SPEKE
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html
>
>   He does no such thing. His "Suppose A and B=85" is a recitation of
> a version of SPEKE that does not hash the password into a group in
> the domain parameter set. It's neither here nor there with respect
> to dragonfly.

Rene describes how Kevin's proposal leads to an attack, in the context
of SPEKE.  I agree it would be clearer if he described it in the
context of Dragonfly, but the attack is more or less the same.


> He further goes on to suggest on a check for "point at
> infinity". Which is already part of dragonfly.
>
>   There is no "error" noted and no "inefficiency" mentioned either.

"...but requires two full scalar multiplications (rather than one
scalar multiplication as, e.g., SPEKE requires)."


>>  - Scott Fluhrer points out the error in Kevin's proposal, and
>>    proposes a flawed "mostly constant time" fix.  Dan and Kevin
>>    embrace it.
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03260.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03263.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03265.html
>
>   As noted in the email thread, the described fix was added to the
> draft at the time. Your opinion on it being "flawed" has already been
> noted.

If you've "noted" the significant sidechannel risk, and the simple
mitigation that's been suggested repeatedly (don't mix in the nonces),
why doesn't your latest TLS-PWD (as of hours ago) include that fix?


>> Feb 2013
>>  - draft-01 is uploaded with flawed sidechannel fix
>>    - also quietly fixes security issue reported by Dylan Clarke
>>      and Feng Hao
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03309.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03529.html
>
>   This is a small sub-group attack possible if one does not check
> validity of received elements. All incarnations of dragonfly-- TLS-PWD,
> EAP-PWD and 802.11 already did this. It is entirely my fault that I left =
that
> crucial step out of the -00 version of the CFRG draft but it is hardly
> a flaw.

I described it as a "security issue", which it is.


>> Apr 2013
>>  - Kevin Igoe mentions a last call for Dragonfly
>>    "The design looks mature, it addresses a real need, and no one
>>     has raised any issues."
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html
>
>   That's correct. You are included in that "no one".

I don't think that's correct:
 * The design remains immature, with a major problem regarding timing
side-channels.
 * I doubt the design addresses an important need.  There are many
better PAKEs, including SRP, which has been standardized and deployed
in TLS (RFC 5054).  In any case, there is little demand for TLS PAKE.
 * Many issues were raised.


>> May 2013
>>  - Feng Hao asks CFRG to consider J-PAKE (an alternative)
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html
>
>   Completely irrelevant.

I think it's relevant that CFRG was made aware of other PAKEs, yet
made no effort to perform a comparative analysis, or question whether
Dragonfly was the best tool for the job.


>> July 2013
>>  - Rene Struik points out spec bugs, raises timing attack issue
>>    again
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03486.html
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html
>
>   "Spec bugs", in other words typos. Yes, he brings up an issue that
> had previously been addressed.

Rene doesn't seem to think the timing attack issue has been properly
addressed, and neither do I.


>>  - IETF 87, CFRG meeting:
>>    - "The author is working on a new (and hopefully final) draft"
>>  http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg
>
>   Sadly, it's not. I have to address the "Spec bugs" and address
> Rene's other comments, none of which demonstrate security flaws.

Rene's last message does, indeed, describe security flaws:

http://www.ietf.org/mail-archive/web/cfrg/current/msg03527.html


>> Aug 2013
>>  - draft-02 is uploaded with modifications to "hunting-and-pecking"
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html
>
>   Don't forget comments dealing with internationalization!
>
>   The change is from a comment received from, if I recall, Russ Housley
> to use the technique from FIPS 186-3 to hide the bias added by the
> modular reduction. Again, a very nice comment, happily accepted.

Another security fix.


>> Sep 2013
>>  - SeongHan Shin asks CFRG to consider AugPAKE (an alternative)
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html
>
>   Completely irrelevant. (Again, not sure why you're have become such
> a cheerleader for AugPAKE).

I'm not.  There are many PAKEs that are superior to Dragonfly *and*
have a clearer IPR situation:  SPAKE2, DH-EKE, SRP, J-PAKE, AugPAKE,
and probably others.


>> Nov/Dec 2013
>>  - Joe Saloway begins TLS-PWD last call, and informs TLS WG that:
>>    "The underlying cryptographic protocol for TLS-PWD has been
>>    reviewed by the IRTF CFRG group with satisfactory results."
>>  http://www.ietf.org/mail-archive/web/tls/current/msg10476.html
>>
>>  - Uproar on TLS WG:
>>
>>    - Many object to lack of formal security analysis:
>>      Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik,
>>      Watson Ladd
>
>   Missing, of course, the caveat "-- except I believe that whenever
> possible the IETF should aim to standardize cryptographic protocols
> that are unencumbered by license fees and patents. If the choice
> arises between a protocol that carries both (provable security and
> Intellectual Property) and a protocol that has neither - I'd strongly
> prefer the latter."

That choice doesn't have to be made.  There are protocols without
current patents *and* with formal security arguments (SPAKE2, DH-EKE,
J-PAKE).


>>    - Many point out better alternatives:
>>      SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin
>
>   And you're all free to write up Internet Drafts on them too!

I did, years ago - RFC 5054.  TLS/SRP is a better PAKE than Dragonfly,
has royalty-free IPR, and has been deployed.


>   In fact, SeongHan Shin has been following me around EMU, IPsec,
> CFRG and now TLS doing just that. After I write a dragonfly I-D he
> writes an AugPAKE I-D. Nothing is stopping you from doing it too.
>
>>    - Security flaws are pointed out by Bodo Moeller and
>>      CodesInChaos
>>    http://www.ietf.org/mail-archive/web/tls/current/msg10708.html
>>    http://www.ietf.org/mail-archive/web/tls/current/msg10768.html
>
>   Bodo's comment has been addressed. I dispute the use of the term
> "security flaw" to describe it but that is consistent with the rest of
> your email.

The flaw is only present in the TLS-PWD draft, not the CFRG draft.

I don't believe your latest TLS-PWD draft fixes it, however.  You
would have to introduce mandatory-to-implement domain parameters, as
in RFC 5054.


>   CodesInChaos suggested using PBKDF2 to hash the password. This
> really provides no additional benefit,, as I noted in a subsequent
> email (see coWPAtty and family attacks against a protocol that uses
> PBKDF2).

Using an "expensive" password hash is standard practice for
server-side password storage, to mitigate the effect of a server-side
compromise.


>>    - Rene Struik and Bodo Moeller dispute that CFRG approved this
>>    http://www.ietf.org/mail-archive/web/tls/current/msg10769.html
>>
>>    http://www.ietf.org/mail-archive/web/tls/current/msg10812.html
>
>   Actually, Rene notes that CFRG has not issued a LC. He does raise
> some comments, many of which are already addressed in the draft
> and he points out the "Spec bug" you allude to earlier. He suggests
> relaxation of one of the restrictions on parameter generation that I
> decline to accept. And he finds some additional typos and an
> erroneous description of point addition. Helpful comments.
>
>>  - Eric Rescorla (TLS WG chair) states:
>>    "we did have a verbal report back from the chair of the CFRG
>>    that they considered it satisfactory"
>>  http://www.ietf.org/mail-archive/web/tls/current/msg10819.html
>
>   Indeed.
>
>   So what you've brought up is that there has been discussion of
> dragonfly on the list and it has, in fact, been reviewed. Quite a few
> comments have been made and resolved, security critical issues have
> been raised and properly addressed.

I agree that Dragonfly has had light review.  Some bugs have been
picked out of the CFRG and TLS drafts, some bugs remain.

What I don't understand is how the CFRG chairs decided the protocol
was "satisfactory".  This seems a decision made by the chairs that
neither reflects CFRG consensus nor was communicated to the broader
CFRG group prior to informing TLS.


Trevor

From rsalz@akamai.com  Fri Dec 13 06:06:14 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC091AE285 for ; Fri, 13 Dec 2013 06:06:14 -0800 (PST)
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, RP_MATCHES_RCVD=-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 mp4sp8sl4kM5 for ; Fri, 13 Dec 2013 06:06:10 -0800 (PST)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id A9B371AD6BF for ; Fri, 13 Dec 2013 06:06:08 -0800 (PST)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F1C63482C0; Fri, 13 Dec 2013 14:06:01 +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 E5232482BC; Fri, 13 Dec 2013 14:06:01 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id C65FE2FD51; Fri, 13 Dec 2013 14:06:01 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.14]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Fri, 13 Dec 2013 09:06:01 -0500
From: "Salz, Rich" 
To: Eric Rescorla 
Date: Fri, 13 Dec 2013 09:06:00 -0500
Thread-Topic: [TLS] TLS Charter Revision
Thread-Index: Ac73ohcPHm+8nAS4TCKUmzXBUPZLqwAag0Gw
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711E4675369@USMBX1.msg.corp.akamai.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>  <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@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
Cc: "" 
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 14:06:15 -0000

On Thu, Dec 12, 2013 at 11:22 PM, Salz, Rich  wrote:
> I agree with Marsh that PFS should be included.

> Can you elaborate more on this? TLS already supports PFS, so are you argu=
ing we should maintain that support or that we should strip out all non-PFS=
 cipher suites (see the thread on static RSA...)

I think we should have an explicit discussion point if PFS is a MUST or a S=
HOULD.

>> I would like to add a bullet that says backward compatibility with previ=
ous  versions is not a requirement. Given all that downgrade fallback issue=
s that continually arise here, we should strongly consider if the right thi=
ng to do is just break the chain.

> I think this is actually backwards: it's precisely having some sort of se=
cure backward negotiation that allows for clean deployment. The problem is =
that people have screwed up those mechanisms. If we just do a clean break t=
here is no chance that secure version detection will work.

So do we think the problem will be solved this time around?  I don't know, =
so I guess it goes into the discussion threads.

	/r$

--
Principal Security Engineer
Akamai Technology
Cambridge, MA

From TurnerS@ieca.com  Fri Dec 13 07:54:29 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98431AE2C0 for ; Fri, 13 Dec 2013 07:54:29 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 luY5RTX2dP2M for ; Fri, 13 Dec 2013 07:54:26 -0800 (PST)
Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [64.5.38.13]) by ietfa.amsl.com (Postfix) with ESMTP id EF33B1ADBF7 for ; Fri, 13 Dec 2013 07:54:25 -0800 (PST)
Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id AE3D7CBC6003; Fri, 13 Dec 2013 09:54:19 -0600 (CST)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 82FDFCBC5F85 for ; Fri, 13 Dec 2013 09:54:19 -0600 (CST)
Received: from [96.231.219.103] (port=59166 helo=[192.168.1.5]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VrV4D-0000Ql-Jr; Fri, 13 Dec 2013 09:54:18 -0600
From: Sean Turner 
Content-Type: multipart/signed; boundary="Apple-Mail=_04771388-67F5-48AB-8A62-F66AEEA0C686"; protocol="application/pkcs7-signature"; micalg=sha1
Message-Id: <1D142D8E-2BBE-4BD2-B454-A07A7D31ECD1@ieca.com>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Date: Fri, 13 Dec 2013 10:54:58 -0500
References:  <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net> 
To: cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org
In-Reply-To: 
X-Mailer: Apple Mail (2.1822)
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.219.103
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([192.168.1.5]) [96.231.219.103]:59166
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 11
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Subject: Re: [TLS] [Cfrg] [saag] Question regarding CFRG process
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 15:54:29 -0000

--Apple-Mail=_04771388-67F5-48AB-8A62-F66AEEA0C686
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

All further responses to this thread need to be sent to the CFRG list =
not the TLS or SAAG list.

spt

On Dec 13, 2013, at 05:29, Trevor Perrin  wrote:

> Dan, all,
>=20
> My message was directed at the CFRG chairs.  I believe CFRG consensus
> has been misrepresented regarding Dragonfly.
>=20
> I'd appreciate if the chairs would respond to this.
>=20
>=20
> Regarding Dan's objections to my summary, I attempt to set the record
> straight below.
>=20
> On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins  =
wrote:
>>=20
>>>=20
>>> Below is a summary of all CFRG discussion of Dragonfly.
>>>=20
>>> =3D=3D=3D=3D=3D
>>>=20
>>> Feb 2008
>>> - Dan Harkins proposes early Dragonfly to CFRG
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg02205.html
>>>=20
>>> - Scott Fluhrer breaks it
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg02206.html
>>=20
>>  An event mentioned in the acknowledgments. Thank you Scott.
>> His review and comments have been most helpful.
>>=20
>>>=20
>>> Nov 2011
>>> - David McGrew appoints Kevin Igoe as CFRG co-chair
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html
>>=20
>>  Completely and utterly irrelevant.
>>=20
>>> Dec 2011
>>> - Dan Harkins asks CFRG to look at TLS-PWD, based on Dragonfly
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html
>>>=20
>>> - Scott Fluhrer points out a problem
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03045.html
>>=20
>>  A simple "sanity" check that the an ECC point is not "infinity". =
Again,
>> a good comment.
>=20
> A crucial security check!
>=20
>=20
>>> - Adam Back questions necessity of it, and lack of security
>>>   analysis
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html
>>=20
>>  He does no such thing. He notices that SRP is not mentioned in the
>> draft. Quite true. And he asks what key exchange is being implemented
>> because "its harder than it looks". Which is also quite true.
>=20
> I believe my description is accurate.
>=20
>=20
>>> Jan 2012
>>> - Kevin Igoe's first email to CFRG:
>>>   "I really like this idea & can find no problems."
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html
>>>=20
>>> - Jonathan Katz questions lack of security analysis, points out
>>>   problems
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html
>>=20
>>  Yes, helpful comments on the draft. The susceptibility to attack =
under
>> the random oracle model is, in fact, mentioned in my slide deck when
>> I presented to the CFRG in Paris at IETF 83. It is a highly contrived
>> scenario and completely unlikely a real world protocol but it does =
raise
>> the question of making a formal proof in that model.
>>=20
>>  You should link to my slide deck in your next broadside.
>=20
> The random oracle model is a well-accepted methodology for analyzing
> crypto protocols.
>=20
> The SPEKE protocol, which Dragonfly is based on, has some degree of
> formal security proof in the random oracle model.  If this proof does
> not carry over to Dragonfly, that's a source of concern:
>=20
> https://eprint.iacr.org/2001/057.pdf
>=20
>=20
>>> March 2012
>>> - At IETF 83 CFRG meeting, concerns are raised about:
>>>   - SPEKE patents
>>>   - necessity of a new scheme
>>>   - timing attacks
>>>   - non-augmented properties
>>> http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt
>>=20
>>  Wow, you make it sound as if you were there. But you weren't. And
>> your summary is not an accurate description of the meeting.
>=20
> I wasn't there.  I believe my summary of the minutes is accurate.
>=20
>=20
>> The
>> sole mention in the minutes of SPEKE is from me.
>=20
> """
> Yoav Nir - there are no IPR?  Really?  Is it really enough different
> from speke that they won't go after.
> """
>=20
>=20
>> And the "concerns"
>> are a recitation of comments received. That's how it works. You get
>> comments and you resolve them.
>=20
> The "concerns" seem critical of the whole enterprise:
> - "there are no IPR?  Really?"
> - "Why the not use what IEEE already had defined in P1363"
> - "The difference between the scheme and SRP.  Here both
>    sides need to have same secret."
> - "could you scheme be made to be like SRP."
>=20
> This don't sound like CFRG approval.  Yet after no significant further
> discussion, at IETF 84 the CFRG chair claims:
>=20
> """
> Kevin Igoe: We approve of it, very clear and usable for general =
setting.
> """
>=20
>=20
>>> May 2012
>>> - Kevin Igoe points out a limitation due to "hunting-and-pecking"
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html
>>=20
>>  He does no such thing. He just said that if the prime defining the
>> curve p =3D 3 mod 4 that it's easier to compute the square root.
>=20
> Kevin recommended constraining Dragonfly to elliptic curves over those =
fields.
>=20
> This would eliminate Curve25519, and probably some other curves.
>=20
>=20
>>> - Zhou Sujing and Dan have an exchange that's hard to follow.
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03115.html
>>>=20
>>> July 2012
>>> - At IETF 84 TLS meeting (CFRG does not meet):
>>>   - Kevin Igoe informs TLS WG, as the CFRG chair:
>>>     "We approve of it, very clear and usable for general setting."
>>> http://www.ietf.org/proceedings/84/minutes/minutes-84-tls
>>=20
>>  Also note the comment: "Tie Dragonfly into EST would be very useful"
>> Yes, it would.
>=20
> I appreciate that the CFRG chairs are fond of Dragonfly.
>=20
> I'd like to understand where this approval comes from.
>=20
>=20
>>> Oct 2012
>>> - Kevin Igoe calls CFRG attention to Dragonfly draft-00
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03214.html
>>>=20
>>> - Jonathan Katz asks for a security proof - there is none
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03215.html
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html
>>=20
>>  Correct. There is no formal proof of security. See my slides from
>> IETF 83.
>=20
> I read Jonathan's re-iteration of this point as expressing concern.
>=20
>=20
>>> Dec 2012
>>> - Kevin Igoe calls CFRG attention to Dragonfly
>>>   - raises timing attack issue, proposes 2 fixes, including
>>>     rediscovery of Dan's original broken method (2008)
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html
>>=20
>>  This is further discussion on addressing a side channel attack.
>> Your attempt to spin this as "broken" is somewhat desperate.
>=20
> Kevin's paragraph starting "A possible fix" is a rediscovery of the
> older Dragonfly technique which Scott Fluhrer broke in 2008.
>=20
>=20
>>> - Rene Struik points out the error in Kevin's proposal, and
>>>   the inefficiency of Dragonfly relative to SPEKE
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html
>>=20
>>  He does no such thing. His "Suppose A and B=85" is a recitation of
>> a version of SPEKE that does not hash the password into a group in
>> the domain parameter set. It's neither here nor there with respect
>> to dragonfly.
>=20
> Rene describes how Kevin's proposal leads to an attack, in the context
> of SPEKE.  I agree it would be clearer if he described it in the
> context of Dragonfly, but the attack is more or less the same.
>=20
>=20
>> He further goes on to suggest on a check for "point at
>> infinity". Which is already part of dragonfly.
>>=20
>>  There is no "error" noted and no "inefficiency" mentioned either.
>=20
> "...but requires two full scalar multiplications (rather than one
> scalar multiplication as, e.g., SPEKE requires)."
>=20
>=20
>>> - Scott Fluhrer points out the error in Kevin's proposal, and
>>>   proposes a flawed "mostly constant time" fix.  Dan and Kevin
>>>   embrace it.
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03260.html
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03263.html
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03265.html
>>=20
>>  As noted in the email thread, the described fix was added to the
>> draft at the time. Your opinion on it being "flawed" has already been
>> noted.
>=20
> If you've "noted" the significant sidechannel risk, and the simple
> mitigation that's been suggested repeatedly (don't mix in the nonces),
> why doesn't your latest TLS-PWD (as of hours ago) include that fix?
>=20
>=20
>>> Feb 2013
>>> - draft-01 is uploaded with flawed sidechannel fix
>>>   - also quietly fixes security issue reported by Dylan Clarke
>>>     and Feng Hao
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03309.html
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03529.html
>>=20
>>  This is a small sub-group attack possible if one does not check
>> validity of received elements. All incarnations of dragonfly-- =
TLS-PWD,
>> EAP-PWD and 802.11 already did this. It is entirely my fault that I =
left that
>> crucial step out of the -00 version of the CFRG draft but it is =
hardly
>> a flaw.
>=20
> I described it as a "security issue", which it is.
>=20
>=20
>>> Apr 2013
>>> - Kevin Igoe mentions a last call for Dragonfly
>>>   "The design looks mature, it addresses a real need, and no one
>>>    has raised any issues."
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html
>>=20
>>  That's correct. You are included in that "no one".
>=20
> I don't think that's correct:
> * The design remains immature, with a major problem regarding timing
> side-channels.
> * I doubt the design addresses an important need.  There are many
> better PAKEs, including SRP, which has been standardized and deployed
> in TLS (RFC 5054).  In any case, there is little demand for TLS PAKE.
> * Many issues were raised.
>=20
>=20
>>> May 2013
>>> - Feng Hao asks CFRG to consider J-PAKE (an alternative)
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html
>>=20
>>  Completely irrelevant.
>=20
> I think it's relevant that CFRG was made aware of other PAKEs, yet
> made no effort to perform a comparative analysis, or question whether
> Dragonfly was the best tool for the job.
>=20
>=20
>>> July 2013
>>> - Rene Struik points out spec bugs, raises timing attack issue
>>>   again
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03486.html
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html
>>=20
>>  "Spec bugs", in other words typos. Yes, he brings up an issue that
>> had previously been addressed.
>=20
> Rene doesn't seem to think the timing attack issue has been properly
> addressed, and neither do I.
>=20
>=20
>>> - IETF 87, CFRG meeting:
>>>   - "The author is working on a new (and hopefully final) draft"
>>> http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg
>>=20
>>  Sadly, it's not. I have to address the "Spec bugs" and address
>> Rene's other comments, none of which demonstrate security flaws.
>=20
> Rene's last message does, indeed, describe security flaws:
>=20
> http://www.ietf.org/mail-archive/web/cfrg/current/msg03527.html
>=20
>=20
>>> Aug 2013
>>> - draft-02 is uploaded with modifications to "hunting-and-pecking"
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html
>>=20
>>  Don't forget comments dealing with internationalization!
>>=20
>>  The change is from a comment received from, if I recall, Russ =
Housley
>> to use the technique from FIPS 186-3 to hide the bias added by the
>> modular reduction. Again, a very nice comment, happily accepted.
>=20
> Another security fix.
>=20
>=20
>>> Sep 2013
>>> - SeongHan Shin asks CFRG to consider AugPAKE (an alternative)
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html
>>=20
>>  Completely irrelevant. (Again, not sure why you're have become such
>> a cheerleader for AugPAKE).
>=20
> I'm not.  There are many PAKEs that are superior to Dragonfly *and*
> have a clearer IPR situation:  SPAKE2, DH-EKE, SRP, J-PAKE, AugPAKE,
> and probably others.
>=20
>=20
>>> Nov/Dec 2013
>>> - Joe Saloway begins TLS-PWD last call, and informs TLS WG that:
>>>   "The underlying cryptographic protocol for TLS-PWD has been
>>>   reviewed by the IRTF CFRG group with satisfactory results."
>>> http://www.ietf.org/mail-archive/web/tls/current/msg10476.html
>>>=20
>>> - Uproar on TLS WG:
>>>=20
>>>   - Many object to lack of formal security analysis:
>>>     Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik,
>>>     Watson Ladd
>>=20
>>  Missing, of course, the caveat "-- except I believe that whenever
>> possible the IETF should aim to standardize cryptographic protocols
>> that are unencumbered by license fees and patents. If the choice
>> arises between a protocol that carries both (provable security and
>> Intellectual Property) and a protocol that has neither - I'd strongly
>> prefer the latter."
>=20
> That choice doesn't have to be made.  There are protocols without
> current patents *and* with formal security arguments (SPAKE2, DH-EKE,
> J-PAKE).
>=20
>=20
>>>   - Many point out better alternatives:
>>>     SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin
>>=20
>>  And you're all free to write up Internet Drafts on them too!
>=20
> I did, years ago - RFC 5054.  TLS/SRP is a better PAKE than Dragonfly,
> has royalty-free IPR, and has been deployed.
>=20
>=20
>>  In fact, SeongHan Shin has been following me around EMU, IPsec,
>> CFRG and now TLS doing just that. After I write a dragonfly I-D he
>> writes an AugPAKE I-D. Nothing is stopping you from doing it too.
>>=20
>>>   - Security flaws are pointed out by Bodo Moeller and
>>>     CodesInChaos
>>>   http://www.ietf.org/mail-archive/web/tls/current/msg10708.html
>>>   http://www.ietf.org/mail-archive/web/tls/current/msg10768.html
>>=20
>>  Bodo's comment has been addressed. I dispute the use of the term
>> "security flaw" to describe it but that is consistent with the rest =
of
>> your email.
>=20
> The flaw is only present in the TLS-PWD draft, not the CFRG draft.
>=20
> I don't believe your latest TLS-PWD draft fixes it, however.  You
> would have to introduce mandatory-to-implement domain parameters, as
> in RFC 5054.
>=20
>=20
>>  CodesInChaos suggested using PBKDF2 to hash the password. This
>> really provides no additional benefit,, as I noted in a subsequent
>> email (see coWPAtty and family attacks against a protocol that uses
>> PBKDF2).
>=20
> Using an "expensive" password hash is standard practice for
> server-side password storage, to mitigate the effect of a server-side
> compromise.
>=20
>=20
>>>   - Rene Struik and Bodo Moeller dispute that CFRG approved this
>>>   http://www.ietf.org/mail-archive/web/tls/current/msg10769.html
>>>=20
>>>   http://www.ietf.org/mail-archive/web/tls/current/msg10812.html
>>=20
>>  Actually, Rene notes that CFRG has not issued a LC. He does raise
>> some comments, many of which are already addressed in the draft
>> and he points out the "Spec bug" you allude to earlier. He suggests
>> relaxation of one of the restrictions on parameter generation that I
>> decline to accept. And he finds some additional typos and an
>> erroneous description of point addition. Helpful comments.
>>=20
>>> - Eric Rescorla (TLS WG chair) states:
>>>   "we did have a verbal report back from the chair of the CFRG
>>>   that they considered it satisfactory"
>>> http://www.ietf.org/mail-archive/web/tls/current/msg10819.html
>>=20
>>  Indeed.
>>=20
>>  So what you've brought up is that there has been discussion of
>> dragonfly on the list and it has, in fact, been reviewed. Quite a few
>> comments have been made and resolved, security critical issues have
>> been raised and properly addressed.
>=20
> I agree that Dragonfly has had light review.  Some bugs have been
> picked out of the CFRG and TLS drafts, some bugs remain.
>=20
> What I don't understand is how the CFRG chairs decided the protocol
> was "satisfactory".  This seems a decision made by the chairs that
> neither reflects CFRG consensus nor was communicated to the broader
> CFRG group prior to informing TLS.
>=20
>=20
> Trevor
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg


--Apple-Mail=_04771388-67F5-48AB-8A62-F66AEEA0C686
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww
ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE
ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT
AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn
tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb
ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg
wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4
rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB
njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD
VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll
Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB
CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE
kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1
N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th
GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i
Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ
v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE
eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi
/aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48
OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM
MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C
CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTEzMTIxMzE1NTQ1OFowIwYJKoZIhvcNAQkEMRYEFKU2rnUjd7xUWmuJTj9nahlB
eDcAMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C
CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF
Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQBhRRDfHjayGOsDbfUdp3B9UeGZ
XcBns4HVT15a9FuzoB+lBu5Auf482PejB/gf7s9sEsrYXxeTv3n6y/7CwbZ1z2rvLQAI0B4HyeIf
szNTYcZ9dK2PxXcJ9umBeqPY/WwbQbxOjiCf8BO2kzx+T/TFfWLB8raeifyjoQpYWJVZeDBg31NJ
m2dCG/8NdmjJGtwW0zi3Vn2yo7OUXmL1wv+Tk3RPgK8eeU40mvslQqMf3QyNam7z71o4EgP4Pj+z
tBKNvCsA7EWjG/fI+ivz99cq/bL9P21+2bUiN6K/0mp9ZY5DtISWbGLg7cn1awyj73wjam9VmOv6
stWpNK4dPD+MAAAAAAAA

--Apple-Mail=_04771388-67F5-48AB-8A62-F66AEEA0C686--

From iesg-secretary@ietf.org  Fri Dec 13 09:16:11 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10C61ADF43; Fri, 13 Dec 2013 09:16:11 -0800 (PST)
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 5R0Q3UAgDs6z; Fri, 13 Dec 2013 09:16:08 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 867F01AD8EC; Fri, 13 Dec 2013 09:16:08 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <20131213171608.10285.15352.idtracker@ietfa.amsl.com>
Date: Fri, 13 Dec 2013 09:16:08 -0800
Cc: tls@ietf.org
Subject: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@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, 13 Dec 2013 17:16:12 -0000

The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'Transport Layer Security (TLS) Application Layer Protocol Negotiation
   Extension'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-12-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document describes a Transport Layer Security (TLS) extension
   for application layer protocol negotiation within the TLS handshake.
   For instances in which the TLS connection is established over a well
   known TCP/IP port not associated with the desired application layer
   protocol, this extension allows the application layer to negotiate
   which protocol will be used within the TLS session.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/ballot/


No IPR declarations have been submitted directly on this I-D.



From paul.hoffman@vpnc.org  Fri Dec 13 09:27:33 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCCF1AE340; Fri, 13 Dec 2013 09:27:33 -0800 (PST)
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 hxsBE7eFtRqI; Fri, 13 Dec 2013 09:27:31 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DDCE71AE126; Fri, 13 Dec 2013 09:27:31 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rBDHRNAY012228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Dec 2013 10:27:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman 
In-Reply-To: <20131213171608.10285.15352.idtracker@ietfa.amsl.com>
Date: Fri, 13 Dec 2013 09:27:22 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org>
References: <20131213171608.10285.15352.idtracker@ietfa.amsl.com>
To: "" 
X-Mailer: Apple Mail (2.1822)
Cc: The IESG , IETF Discussion 
Subject: Re: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 17:27:33 -0000

The shepherd writeup for this document (current version at =
) is not accurate, and that has a major effect on the IETF Last =
call. For question 9, it says:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(9) How solid is the WG consensus behind this document? Does it =
represent the strong concurrence of a few individuals, with others being =
silent, or does the WG as a whole understand and agree with it?

the document represents strong consensus
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

A hum was taken at IETF 87 for the WG to pick between this proposal and =
another; there were many hums in the room for each, with more for this =
proposal. That hum was not taken to the WG mailing list. Since then, =
many people have given strong reasons to prefer the other proposal for =
technical reasons.

--Paul Hoffman=

From akr@akr.io  Fri Dec 13 11:42:47 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445D81AE3D9; Fri, 13 Dec 2013 11:42:47 -0800 (PST)
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 876U4vE7Wit8; Fri, 13 Dec 2013 11:42:43 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 291FA1ADF6B; Fri, 13 Dec 2013 11:42:42 -0800 (PST)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id 0D21F60A2D; Fri, 13 Dec 2013 19:42:35 +0000 (GMT)
Message-ID: <52AB6323.2050107@akr.io>
Date: Fri, 13 Dec 2013 19:42:27 +0000
From: Alyssa Rowan 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <20131213171608.10285.15352.idtracker@ietfa.amsl.com> <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org>
In-Reply-To: <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: iesg@ietf.org, ietf@ietf.org
Subject: Re: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 19:42:47 -0000

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

On 13/12/2013 17:27, Paul Hoffman wrote:

> A hum was taken at IETF 87 for the WG to pick between this
> proposal and another; there were many hums in the room for each,
> with more for this proposal. That hum was not taken to the WG
> mailing list. Since then, many people have given strong reasons to
> prefer the other proposal for technical reasons.

Strongly seconded. This cryptographic protocol is not ready yet, and
requires careful reconsideration on-list, and at the very least a
public on-list call for consensus - which it does not seem to have
received - before deciding whether it is appropriate to proceed.

• At IETF 88's Technical Plenary, serious concerns were raised about
  mass surveillance of data and metadata by Nation State Adversaries.

• Decisions were made at IETF 88, with overwhelming consensus, that
  new protocols MUST consider the impact they have on mass surveillance.

• ALPN has no such consideration. It leaks plaintext metadata which its
  competitor, NPN, encrypts. This makes ALPN quantitatively more
  vulnerable to passive attackers, including Nation State Adversaries.
  [It may be that a future TLS 1.3 can encrypt the whole ClientHello;
  but that is not the current state-of-play. As it stands, it would be
  plaintext.]

• Profound concerns have been raised about the protocol and the voting
  process. A call has been made for at the very least the opportunity
  to stop, rewind, and rethink whether ALPN is appropriate, and for a
  new consensus call.
  

• The chairs and AD have refused, and simply ignored the concerns.
  
  

• It is publicly known that Nation State Adversaries have attempted to,
  and in some cases succeeded in, weakening or backdooring
  cryptographic standards. TLS has very likely been a main target of
  this, as the most-used cryptographic standard on the internet.



• Concerns have been raised that one or more of the chairs or AD may
  have a conflict of interest and appear to be railroading the process.
  

• As discussed at the IETF 88 Plenary, especially in light of the
  Snowden BULLRUN disclosures, it is absolutely vital that
  cryptographic standards such as TLS are devised openly,
  transparently, and with clear, public consensus as being the best
  available solution.

• That has not happened with the ALPN extension to date.

Therefore, I second Brian's proposal for a new consensus call and
discussion on ALPN, and Paul's appeal to the IETF LC: in my opinion,
it is wholly premature to advance ALPN to Proposed Standard at this time.

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

iQIcBAEBCgAGBQJSq2MjAAoJEOyEjtkWi2t6L0MQAIxsdB4aAZvw6XdiIttRzaHR
bmvvGCScckyUfSFS6t2V36oxp9FNmkEzaXUTpUcRMrJsRlsXgjExlIsYKYqvtPzi
x8zPRyc2Yp61zTj2tZI0tlYDwQ3M53Pfy1br+0eLfqqy+dRaPsRyQWHi9FlMLU5u
eGaA1KMgUOAZSxNB9oliJOXmSj+DcQpcWpp+D3piYBSINUYrY3xtO31khhG0f8xX
EOLH7pMwVkyEhQOG83qA801Yt45j0cr6X7Wg34jFhCfCR1xQDbkMLabAXHYTWmdo
C4cmJQVTHgnYXiIPdwXR87iPpAevBNpoxNQzps1LoHYEM6xpqDwln9aExyaPAiT6
4fV+Wr5C22H/Xh+wbkVFPRQEvZbbjDJKGSWyB0i6YKgmUxrF+VQHlJKFrS2TwEni
nmIIcFFN/bo2f8bwbtLf2bEQRAzz8R2N5gVeLQJcoWEz4lcl/1F2E82tZnd9ArLU
XGH5gawLh3bqLZRFUU0VfCYfQSrGy2PtIViyKSLKLCOlI7onL9CGB3jtSuqQDHep
8h3yeSk68d0gVVLmRUmx9aZMbOivZOP54t+Q8wwtluuHnGKdN2NU3oAFSfmDKcRG
cEWsddc44tF1eANVWXxJsHe8LvxUA6UCvI19kLxuNcV4RL8lCzWr38YaUVRpqXby
cYdzEMv6nqKpAynigGgh
=u0As
-----END PGP SIGNATURE-----

From ynir@checkpoint.com  Fri Dec 13 13:43:26 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0131ADFC9; Fri, 13 Dec 2013 13:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level: 
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 dpD_QRIz9wx0; Fri, 13 Dec 2013 13:43:24 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF521ADED5; Fri, 13 Dec 2013 13:43:23 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rBDLhEJv018598; Fri, 13 Dec 2013 23:43:14 +0200
X-CheckPoint: {52AB7BC4-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.146]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Fri, 13 Dec 2013 23:43:14 +0200
From: Yoav Nir 
To: Alyssa Rowan 
Thread-Topic: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
Thread-Index: AQHO+DuLUg8FUfdLCEiXwUM7nt4jjppShqYA
Date: Fri, 13 Dec 2013 21:43:13 +0000
Message-ID: 
References: <20131213171608.10285.15352.idtracker@ietfa.amsl.com> <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org> <52AB6323.2050107@akr.io>
In-Reply-To: <52AB6323.2050107@akr.io>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.49]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" , "" , "" 
Subject: Re: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 21:43:26 -0000

Hi Alyssa

I mostly agree with the facts presented below. However:

- I object to characterizing this as a "cryptographic protocol". This is si=
mple networking. Just as Ethernet tells us there's IP inside, and IP tells =
us there's TCP inside, and TCP tells us about port 443 (which used to mean =
https), we now have TLS tell us whether there's HTTP/1 or HTTP/2 inside. Th=
is is needed because the HTTP specifications and implementations don't hand=
le version negotiation well. This can have security implications, but it's =
not a cryptographic protocol.

- Mass surveillance is a concern. It is not the only concern. The IP addres=
s of the server I'm accessing leaks far more important information then whe=
ther I'm using HTTP/1 or HTTP/2. This may also leak the browser version, bu=
t that can also be readily recognized by looking at the ciphersuite list. S=
ure, others (including me) raised all sorts of possibilities for extra used=
 for ALPN. For now, there's only the two versions of HTTP.  We haven't hear=
d anyone explain what good knowing the version of HTTP does to a nation sta=
te adversary.

- The chairs did not ignore the requests. They rejected them. You can still=
 disagree. One thing is missing from the account of the hum at IETF 87. Yes=
, there were some voices for each proposal, and that does not a consensus m=
ake. But then Sean asked a different question, and got overwhelming support=
 for the statement that reaching a decision right then was important, and t=
hat we didn't want to wait and discuss it more. That is why the choice betw=
een them was done as an almost vote - nearly all of us at the time preferre=
d to get *a* decision rather than keep hashing the subject over and over ag=
ain. Rolling back, as people are suggesting now, runs contrary to that cons=
ensus.

- I've read that message suggesting the chairs had conflict of interest. Th=
ere's no question the chairs worked to rush this decision, but my memory is=
 that they mostly wanted to avoid accepting this work item at all. Having a=
ccepted it, they may have had a bias for less radical changes, but I don't =
remember any "railroading".

While I prefer ALPN, I wouldn't consider it tragic to have had NPN. But we =
(in the sense of the IETF, mostly the httpbis group) have a goal for a feat=
ure complete document for HTTP/2 with multiple interoperable implementation=
s in the wild. This requires the negotiation part to be done. Rolling back =
the TLS WG decision now puts that goal at risk, so I oppose it.

Yoav


On Dec 13, 2013, at 9:42 PM, Alyssa Rowan  wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>=20
> On 13/12/2013 17:27, Paul Hoffman wrote:
>=20
>> A hum was taken at IETF 87 for the WG to pick between this
>> proposal and another; there were many hums in the room for each,
>> with more for this proposal. That hum was not taken to the WG
>> mailing list. Since then, many people have given strong reasons to
>> prefer the other proposal for technical reasons.
>=20
> Strongly seconded. This cryptographic protocol is not ready yet, and
> requires careful reconsideration on-list, and at the very least a
> public on-list call for consensus - which it does not seem to have
> received - before deciding whether it is appropriate to proceed.
>=20
> =95 At IETF 88's Technical Plenary, serious concerns were raised about
>  mass surveillance of data and metadata by Nation State Adversaries.
>=20
> =95 Decisions were made at IETF 88, with overwhelming consensus, that
>  new protocols MUST consider the impact they have on mass surveillance.
>=20
> =95 ALPN has no such consideration. It leaks plaintext metadata which its
>  competitor, NPN, encrypts. This makes ALPN quantitatively more
>  vulnerable to passive attackers, including Nation State Adversaries.
>  [It may be that a future TLS 1.3 can encrypt the whole ClientHello;
>  but that is not the current state-of-play. As it stands, it would be
>  plaintext.]
>=20
> =95 Profound concerns have been raised about the protocol and the voting
>  process. A call has been made for at the very least the opportunity
>  to stop, rewind, and rethink whether ALPN is appropriate, and for a
>  new consensus call.
>  
>=20
> =95 The chairs and AD have refused, and simply ignored the concerns.
>  
>  
>=20
> =95 It is publicly known that Nation State Adversaries have attempted to,
>  and in some cases succeeded in, weakening or backdooring
>  cryptographic standards. TLS has very likely been a main target of
>  this, as the most-used cryptographic standard on the internet.
>=20
> 
>=20
> =95 Concerns have been raised that one or more of the chairs or AD may
>  have a conflict of interest and appear to be railroading the process.
>  
>=20
> =95 As discussed at the IETF 88 Plenary, especially in light of the
>  Snowden BULLRUN disclosures, it is absolutely vital that
>  cryptographic standards such as TLS are devised openly,
>  transparently, and with clear, public consensus as being the best
>  available solution.
>=20
> =95 That has not happened with the ALPN extension to date.
>=20
> Therefore, I second Brian's proposal for a new consensus call and
> discussion on ALPN, and Paul's appeal to the IETF LC: in my opinion,
> it is wholly premature to advance ALPN to Proposed Standard at this time.
>=20
> - --=20
> /akr
> -----BEGIN PGP SIGNATURE-----
>=20
> iQIcBAEBCgAGBQJSq2MjAAoJEOyEjtkWi2t6L0MQAIxsdB4aAZvw6XdiIttRzaHR
> bmvvGCScckyUfSFS6t2V36oxp9FNmkEzaXUTpUcRMrJsRlsXgjExlIsYKYqvtPzi
> x8zPRyc2Yp61zTj2tZI0tlYDwQ3M53Pfy1br+0eLfqqy+dRaPsRyQWHi9FlMLU5u
> eGaA1KMgUOAZSxNB9oliJOXmSj+DcQpcWpp+D3piYBSINUYrY3xtO31khhG0f8xX
> EOLH7pMwVkyEhQOG83qA801Yt45j0cr6X7Wg34jFhCfCR1xQDbkMLabAXHYTWmdo
> C4cmJQVTHgnYXiIPdwXR87iPpAevBNpoxNQzps1LoHYEM6xpqDwln9aExyaPAiT6
> 4fV+Wr5C22H/Xh+wbkVFPRQEvZbbjDJKGSWyB0i6YKgmUxrF+VQHlJKFrS2TwEni
> nmIIcFFN/bo2f8bwbtLf2bEQRAzz8R2N5gVeLQJcoWEz4lcl/1F2E82tZnd9ArLU
> XGH5gawLh3bqLZRFUU0VfCYfQSrGy2PtIViyKSLKLCOlI7onL9CGB3jtSuqQDHep
> 8h3yeSk68d0gVVLmRUmx9aZMbOivZOP54t+Q8wwtluuHnGKdN2NU3oAFSfmDKcRG
> cEWsddc44tF1eANVWXxJsHe8LvxUA6UCvI19kLxuNcV4RL8lCzWr38YaUVRpqXby
> cYdzEMv6nqKpAynigGgh
> =3Du0As
> -----END PGP SIGNATURE-----
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From martin.thomson@gmail.com  Fri Dec 13 14:46:55 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE841AE41A; Fri, 13 Dec 2013 14:46:55 -0800 (PST)
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 3cwsu_oTp8FA; Fri, 13 Dec 2013 14:46:52 -0800 (PST)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 57C611AE43E; Fri, 13 Dec 2013 14:46:52 -0800 (PST)
Received: by mail-we0-f182.google.com with SMTP id q59so2545408wes.27 for ; Fri, 13 Dec 2013 14:46:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NLbWZmTbfnHLTCY71nVoZvyEQQleNCg4tVWoL9QXP7Q=; b=ztemlDRNCF/kENJS+0up7kEA2gjvRgIS+WfF4cBcoAn7jAyFT0TEyCaNsLyGTZ/7f3 8JvnwsZfcGXSdl2NgtQtRU8NFDfMG8dGNc4aqjP/m0ctWBequIFG/jXdg9iFNr6vShu8 yJNKqq59d2YWGjqSA9NOSqTIeCTbmh2H40q9mab1GlrOHErrgEsEEG7dWq9Dgg7zLe/N KvfnvZTlUCujRnHLI1enmoNUxYcHLv5iHqxXoeiKZ54NLruuhA06E31G8xdynUOqgx9c vxNx9ItGL9fg1KkD9nyOLgOHTZSIwAqhDGHpw52SJoyA9ROSDgxJ1kN16fOoPywvNQSR ao8Q==
MIME-Version: 1.0
X-Received: by 10.180.188.175 with SMTP id gb15mr4742742wic.50.1386974805523;  Fri, 13 Dec 2013 14:46:45 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Fri, 13 Dec 2013 14:46:45 -0800 (PST)
In-Reply-To: 
References: <20131213171608.10285.15352.idtracker@ietfa.amsl.com> <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org> <52AB6323.2050107@akr.io> 
Date: Fri, 13 Dec 2013 14:46:45 -0800
Message-ID: 
From: Martin Thomson 
To: Yoav Nir 
Content-Type: text/plain; charset=UTF-8
Cc: "" , "" , "" 
Subject: Re: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 13 Dec 2013 22:46:55 -0000

On 13 December 2013 13:43, Yoav Nir  wrote:
> But we (in the sense of the IETF, mostly the httpbis group) have a goal for a feature complete document for HTTP/2 with multiple interoperable implementations in the wild.

As the editor of the spec that stands most to be affected by faffing
around here, I'd be strongly opposed to further delays.

...and don't take this to mean that this is the only reason I believe
we should proceed in this way.  The arguments stacked up against ALPN
are not new.  I've read the arguments presented, and agree with some
points, disagree with others, but on the whole I find them completely
unconvincing.

From sfriedl@cisco.com  Fri Dec 13 16:28:40 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C531AE0F3; Fri, 13 Dec 2013 16:28:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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.001, 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 1yX091-LnWNL; Fri, 13 Dec 2013 16:28:37 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9261ADFAD; Fri, 13 Dec 2013 16:28:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9123; q=dns/txt; s=iport; t=1386980911; x=1388190511; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+1eQ/pJMjfZvA6BNr2hytOrzvc/IGhzeVujgi3oUTpA=; b=XgtvQIfu9fDr9+orszC9UHDCiMLmWpXD5qSbipq4vsGMho3JQoaTFRjZ JAk23AY/H3Ywqe/0vcOxBOejuxaLZJ+PRLHzvuRYUcBujzP+55JpIMyUL PtQafRLIAtqDjWcE6WA8nOzscLdmQFKQdP7IOK+V+23pw/r4AzH7L5gY2 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhUFAB6lq1KtJV2c/2dsb2JhbABZgwo4VbhggSIWdIIlAQEBAwEBAQEaHTQLBQcEAgEIDgMEAQEBCgsJBQQHJwsUCQgCBA4FCBOHYQgNymYXjikbAQEeMQIFBgSDGYETAQOqKoFsgT6BcTk
X-IronPort-AV: E=Sophos;i="4.95,482,1384300800"; d="scan'208";a="288471792"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 14 Dec 2013 00:28:30 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBE0SUmg029615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 14 Dec 2013 00:28:30 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Fri, 13 Dec 2013 18:28:30 -0600
From: "Stephan Friedl (sfriedl)" 
To: Alyssa Rowan 
Thread-Topic: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
Thread-Index: AQHO+DuFs2oYMzPJ906OnKLd/YTTY5pTDMOA//+9RVA=
Date: Sat, 14 Dec 2013 00:28:29 +0000
Message-ID: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C2322C978@xmb-aln-x02.cisco.com>
References: <20131213171608.10285.15352.idtracker@ietfa.amsl.com> <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org> <52AB6323.2050107@akr.io> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.19.81.153]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" , "" , "" 
Subject: Re: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 14 Dec 2013 00:28:40 -0000

I fear that there is a perception that ALPN leaks information like a sieve =
and NPN doesn't leak at all.  Both extensions leak information in plain tex=
t - they just leak different information. =20

NPN leaks the entire list of protocols available on a host/port combination=
 and encrypts the single protocol selected by the client.  When watching a =
single TLS negotiation using NPN, a passive attacker knows all the protocol=
s exposed by a server and therefore has a big head start on identifying the=
 single protocol chosen by the client as well as assessing a server for pot=
ential vulnerabilities to exploit - effectively an instant port scan.  In c=
ontrast ALPN has the client advertising the protocols it supports in plaint=
ext and has the server's selection of a protocol returned in plaintext.  In=
 ALPN the entire list of protocols supported by a given host on a given por=
t is never revealed during a single TLS negotiation.

Also, I agree with Yoav's take on ALPN as simple networking and not a 'cryp=
tographic protocol'.  All ALPN does is provides the protocol to be used for=
 a connection when the port number is no longer definitive.  ALPN is a plai=
n, vanilla extension - whereas NPN does introduce some non-standard twists =
to TLS extension practice in that the negotiation is not encapsulated in th=
e hello messages and that it introduces a padded handshake message between =
the ChangeCipherSpec and Finished messages.

Thanks,

Stephan


> -----Original Message-----
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yoav Nir
> Sent: Friday, December 13, 2013 2:43 PM
> To: Alyssa Rowan
> Cc: ; ; 
> Subject: Re: [TLS] Last Call: 
> (Transport Layer Security (TLS) Application Layer Protocol Negotiation
> Extension) to Proposed Standard
>=20
> Hi Alyssa
>=20
> I mostly agree with the facts presented below. However:
>=20
> - I object to characterizing this as a "cryptographic protocol". This is =
simple
> networking. Just as Ethernet tells us there's IP inside, and IP tells us =
there's
> TCP inside, and TCP tells us about port 443 (which used to mean https), w=
e
> now have TLS tell us whether there's HTTP/1 or HTTP/2 inside. This is nee=
ded
> because the HTTP specifications and implementations don't handle version
> negotiation well. This can have security implications, but it's not a
> cryptographic protocol.
>=20
> - Mass surveillance is a concern. It is not the only concern. The IP addr=
ess of
> the server I'm accessing leaks far more important information then whethe=
r
> I'm using HTTP/1 or HTTP/2. This may also leak the browser version, but t=
hat
> can also be readily recognized by looking at the ciphersuite list. Sure, =
others
> (including me) raised all sorts of possibilities for extra used for ALPN.=
 For
> now, there's only the two versions of HTTP.  We haven't heard anyone
> explain what good knowing the version of HTTP does to a nation state
> adversary.
>=20
> - The chairs did not ignore the requests. They rejected them. You can sti=
ll
> disagree. One thing is missing from the account of the hum at IETF 87. Ye=
s,
> there were some voices for each proposal, and that does not a consensus
> make. But then Sean asked a different question, and got overwhelming
> support for the statement that reaching a decision right then was importa=
nt,
> and that we didn't want to wait and discuss it more. That is why the choi=
ce
> between them was done as an almost vote - nearly all of us at the time
> preferred to get *a* decision rather than keep hashing the subject over a=
nd
> over again. Rolling back, as people are suggesting now, runs contrary to =
that
> consensus.
>=20
> - I've read that message suggesting the chairs had conflict of interest. =
There's
> no question the chairs worked to rush this decision, but my memory is tha=
t
> they mostly wanted to avoid accepting this work item at all. Having accep=
ted
> it, they may have had a bias for less radical changes, but I don't rememb=
er
> any "railroading".
>=20
> While I prefer ALPN, I wouldn't consider it tragic to have had NPN. But w=
e (in
> the sense of the IETF, mostly the httpbis group) have a goal for a featur=
e
> complete document for HTTP/2 with multiple interoperable implementations
> in the wild. This requires the negotiation part to be done. Rolling back =
the TLS
> WG decision now puts that goal at risk, so I oppose it.
>=20
> Yoav
>=20
>=20
> On Dec 13, 2013, at 9:42 PM, Alyssa Rowan  wrote:
>=20
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > On 13/12/2013 17:27, Paul Hoffman wrote:
> >
> >> A hum was taken at IETF 87 for the WG to pick between this proposal
> >> and another; there were many hums in the room for each, with more for
> >> this proposal. That hum was not taken to the WG mailing list. Since
> >> then, many people have given strong reasons to prefer the other
> >> proposal for technical reasons.
> >
> > Strongly seconded. This cryptographic protocol is not ready yet, and
> > requires careful reconsideration on-list, and at the very least a
> > public on-list call for consensus - which it does not seem to have
> > received - before deciding whether it is appropriate to proceed.
> >
> > * At IETF 88's Technical Plenary, serious concerns were raised about
> > mass surveillance of data and metadata by Nation State Adversaries.
> >
> > * Decisions were made at IETF 88, with overwhelming consensus, that
> > new protocols MUST consider the impact they have on mass surveillance.
> >
> > * ALPN has no such consideration. It leaks plaintext metadata which
> > its  competitor, NPN, encrypts. This makes ALPN quantitatively more
> > vulnerable to passive attackers, including Nation State Adversaries.
> >  [It may be that a future TLS 1.3 can encrypt the whole ClientHello;
> > but that is not the current state-of-play. As it stands, it would be
> > plaintext.]
> >
> > * Profound concerns have been raised about the protocol and the voting
> > process. A call has been made for at the very least the opportunity
> > to stop, rewind, and rethink whether ALPN is appropriate, and for a
> > new consensus call.
> >  
> >
> > * The chairs and AD have refused, and simply ignored the concerns.
> >  
> >  
> >
> > * It is publicly known that Nation State Adversaries have attempted
> > to,  and in some cases succeeded in, weakening or backdooring
> > cryptographic standards. TLS has very likely been a main target of
> > this, as the most-used cryptographic standard on the internet.
> >
> >  nsa
> > -campaign-against-encryption.html>
> >
> > * Concerns have been raised that one or more of the chairs or AD may
> > have a conflict of interest and appear to be railroading the process.
> >  
> >
> > * As discussed at the IETF 88 Plenary, especially in light of the
> > Snowden BULLRUN disclosures, it is absolutely vital that
> > cryptographic standards such as TLS are devised openly,
> > transparently, and with clear, public consensus as being the best
> > available solution.
> >
> > * That has not happened with the ALPN extension to date.
> >
> > Therefore, I second Brian's proposal for a new consensus call and
> > discussion on ALPN, and Paul's appeal to the IETF LC: in my opinion,
> > it is wholly premature to advance ALPN to Proposed Standard at this tim=
e.
> >
> > - --
> > /akr
> > -----BEGIN PGP SIGNATURE-----
> >
> >
> iQIcBAEBCgAGBQJSq2MjAAoJEOyEjtkWi2t6L0MQAIxsdB4aAZvw6XdiIttRzaHR
> > bmvvGCScckyUfSFS6t2V36oxp9FNmkEzaXUTpUcRMrJsRlsXgjExlIsYKYqvtPzi
> >
> x8zPRyc2Yp61zTj2tZI0tlYDwQ3M53Pfy1br+0eLfqqy+dRaPsRyQWHi9FlMLU5u
> >
> eGaA1KMgUOAZSxNB9oliJOXmSj+DcQpcWpp+D3piYBSINUYrY3xtO31khhG0f
> 8xX
> >
> EOLH7pMwVkyEhQOG83qA801Yt45j0cr6X7Wg34jFhCfCR1xQDbkMLabAXHYT
> Wmdo
> >
> C4cmJQVTHgnYXiIPdwXR87iPpAevBNpoxNQzps1LoHYEM6xpqDwln9aExyaPA
> iT6
> >
> 4fV+Wr5C22H/Xh+wbkVFPRQEvZbbjDJKGSWyB0i6YKgmUxrF+VQHlJKFrS2Tw
> Eni
> > nmIIcFFN/bo2f8bwbtLf2bEQRAzz8R2N5gVeLQJcoWEz4lcl/1F2E82tZnd9ArLU
> >
> XGH5gawLh3bqLZRFUU0VfCYfQSrGy2PtIViyKSLKLCOlI7onL9CGB3jtSuqQDHe
> p
> >
> 8h3yeSk68d0gVVLmRUmx9aZMbOivZOP54t+Q8wwtluuHnGKdN2NU3oAFSf
> mDKcRG
> >
> cEWsddc44tF1eANVWXxJsHe8LvxUA6UCvI19kLxuNcV4RL8lCzWr38YaUVRpqX
> by
> > cYdzEMv6nqKpAynigGgh
> > =3Du0As
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > 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

From watsonbladd@gmail.com  Fri Dec 13 16:47:32 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D7D1AE00D; Fri, 13 Dec 2013 16:47:32 -0800 (PST)
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_71=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 N4GBsDwcOD2g; Fri, 13 Dec 2013 16:47:31 -0800 (PST)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 594721ADBCD; Fri, 13 Dec 2013 16:47:30 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id w62so2596281wes.3 for ; Fri, 13 Dec 2013 16:47:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=i6HzZsGH0K4dbirMkzBP9dyMupnlFKYsrQ8bJ2oZ9RM=; b=UMkiMPGXLhUB2iG9T2uQakQlKNnyhT9P8BSV4GVDL/o21AqMxMncCCdkH2QRImIjkz 1ebMZxwWQQJGEx9TsCTt+iNSbYWAUz+1vHJC4gwzcLsrA84DFkDaEUSJ9NY/h1waHvV8 47rSWDJ/x6I2FG6oTZAgOR3qe8Rzsb/C9s2x/ZkSj44smtnnRE0B5ZQvpdPNV/7BY2vl /smCDTvODJwDgAE6NOpfHZG9ZYPuifUA/7wr8OP1+A8ipIzNvx8untr+I1CwM3xA/I7R o9mS1kTZBQbz/YK4KiydNmHctgMUyRLkHYmMHu++S3adfiuwlU43onobZudhf3k1cUV6 GgUw==
MIME-Version: 1.0
X-Received: by 10.195.13.234 with SMTP id fb10mr4472197wjd.50.1386982043445; Fri, 13 Dec 2013 16:47:23 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Fri, 13 Dec 2013 16:47:23 -0800 (PST)
In-Reply-To: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C2322C978@xmb-aln-x02.cisco.com>
References: <20131213171608.10285.15352.idtracker@ietfa.amsl.com> <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org> <52AB6323.2050107@akr.io>  <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C2322C978@xmb-aln-x02.cisco.com>
Date: Fri, 13 Dec 2013 16:47:23 -0800
Message-ID: 
From: Watson Ladd 
To: "Stephan Friedl (sfriedl)" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" , "" , "" 
Subject: Re: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 14 Dec 2013 00:47:33 -0000

On Fri, Dec 13, 2013 at 4:28 PM, Stephan Friedl (sfriedl)
 wrote:
> I fear that there is a perception that ALPN leaks information like a siev=
e and NPN doesn't leak at all.  Both extensions leak information in plain t=
ext - they just leak different information.
>
> NPN leaks the entire list of protocols available on a host/port combinati=
on and encrypts the single protocol selected by the client.  When watching =
a single TLS negotiation using NPN, a passive attacker knows all the protoc=
ols exposed by a server and therefore has a big head start on identifying t=
he single protocol chosen by the client as well as assessing a server for p=
otential vulnerabilities to exploit - effectively an instant port scan.  In=
 contrast ALPN has the client advertising the protocols it supports in plai=
ntext and has the server's selection of a protocol returned in plaintext.  =
In ALPN the entire list of protocols supported by a given host on a given p=
ort is never revealed during a single TLS negotiation.

Clients are much more interesting to watch than servers. So long as
ALPN and NPN are negotiating among a small number of protocol versions
this doesn't matter. But if we include various options in HTTP this
makes fingerprinting easier if they are exposed in ALPN. Scanning for
what a server supports looks like a bunch of diverse clients
connecting: it isn't going to get noticed anyway. But knowing that a
client supports the latest Firefox+a particular extension because it
has support for a protocol over 443 is very useful. I don't think the
extra few bits matter, but we should remind everyone that they should
be very few bits. (In particular the inevitable hack advertising IRC
support via ALPN is a terrible idea).

>
> Also, I agree with Yoav's take on ALPN as simple networking and not a 'cr=
yptographic protocol'.  All ALPN does is provides the protocol to be used f=
or a connection when the port number is no longer definitive.  ALPN is a pl=
ain, vanilla extension - whereas NPN does introduce some non-standard twist=
s to TLS extension practice in that the negotiation is not encapsulated in =
the hello messages and that it introduces a padded handshake message betwee=
n the ChangeCipherSpec and Finished messages.
>

ALPN needs to be negotiated and tied into the session. Otherwise you
can have fun playing wrong protocol with right authority games.

Sincerely,
Watson Ladd

From akr@akr.io  Fri Dec 13 16:50:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3B41AE173; Fri, 13 Dec 2013 16:50:51 -0800 (PST)
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 H33ls9MJYF_f; Fri, 13 Dec 2013 16:50:47 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 63EF21AE14B; Fri, 13 Dec 2013 16:50:47 -0800 (PST)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id 56C85602C5; Sat, 14 Dec 2013 00:50:39 +0000 (GMT)
Message-ID: <52ABAB5E.4040506@akr.io>
Date: Sat, 14 Dec 2013 00:50:38 +0000
From: Alyssa Rowan 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: ietf@ietf.org, tls@ietf.org, iesg@ietf.org
References: <20131213171608.10285.15352.idtracker@ietfa.amsl.com> <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org> <52AB6323.2050107@akr.io> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 14 Dec 2013 00:50:51 -0000

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

On 13/12/2013 21:43, Yoav Nir wrote:

> I mostly agree with the facts presented below. However: - I object
>  to characterizing this as a "cryptographic protocol".

Fair enough. Poor choice of words on my part. ALPN is a metadata
extension to the cryptographic protocol, TLS.

> [...]we now have TLS tell us whether there's HTTP/1 or HTTP/2 
> inside.

The I-D doesn't seem to limit this to HTTP/1 or HTTP/2: it's a general
extension, which suggests a general use case.

If HTTP/(1|2) is all it's really intended to be used for at this time,
(your and Martin's response makes me think maybe it is), then perhaps
we SHOULD only use it for that at this time.

I think that would substantially weaken my objection. How would others
feel about that?

And then later (TLS 1.3?), if we can encrypt the ClientHello [How?
Ed25519+Elligator2 key from DNSSEC, or something? Hm... not sure.],
then ALPN is fine. That might be a way forward, perhaps.

> - Mass surveillance is a concern. It is not the only concern.

I agree (though it is of growing importance). Little metadata leaks
can still be important where they intersect.

> We haven't heard anyone explain what good knowing the version of 
> HTTP does to a nation state adversary.

Hypothetical case study:

If NSA had, for example, a practical attack on the RSA-RC4-(SHA|MD5)
ciphersuites that used likely known-plaintext prefixes ("GET /"...?)
along with biases in the keystream to, as they would say, "enable"
partial key recovery, ALPN would mean they don't even have to guess
which prefix to try, and might be able to make it easier for non-HTTP
use of TLS.

Of course, that's just my own guess, and the BIG vuln there is RC4
(which can be (I hope) dealt with by Adam's draft).

ALPN would, I appreciate, be a help in packet classification/shallow
analysis, mostly if more widely deployed among other protocols.

I note Stephan's comments about NPN's own leaks, and so NPN could be
more useful to them in "CNE" (hacking), when the gloves come off.
There are benefits and drawbacks to both - I accept that.

> - The chairs did not ignore the requests. They rejected them.

They said that no substantive new information had been presented since
the initial consensus call and therefore the consensus should stand.
(They did state that objections could be raised during IETF LC: that's
what's happening now.)

The disclosures re: BULLRUN and the IETF 88 TP seemed simply
unaddressed. I find that baffling. It is, as you say, rushed. It looks
like railroading, and I'm sure all want to avoid that appearance.

If the WG indeed knew then what we know now, then if we took a quick
consensus on-list, it'd have a similar result, and all would see that
it has been reached openly and transparently, which would address the
concerns that have been raised?

> While I prefer ALPN, I wouldn't consider it tragic to have had 
> NPN.

Similarly, I prefer NPN, but I'm not vehemently against ALPN,
particularly if limited in scope to HTTP/1 or /2 until ClientHello can
be encrypted in TLS 1.3.


On 13/12/2013 22:46, Martin Thomson wrote:

> As the editor of the spec that stands most to be affected by 
> faffing around here, I'd be strongly opposed to further delays.

Sorry! I do thank you for baking TLS in - I feel that's important -
and I really do apologise for the 'faff'. (This is not really how I
wanted to introduce myself, believe me!)

I feel that, as an extension to a protocol with a billion-dollar
target painted on it, it needs to be thought through, not rushed through.

I want to make sure legitimate concerns raised on-list are addressed,
not shortcutted, and that a transparent consensus, with current
information, not stale, can be reached.

A week or so, maybe?

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

iQIcBAEBCgAGBQJSq6teAAoJEOyEjtkWi2t6WvUQAJgCudaxqlway/54sjALvc0+
lHqJJD93zvPOP5zUzWQn/UaSE07ky4GviCIGfDkeKCtPlvUOX6gaUDg785o9QB//
FjT3Fp4s+81vMux0/dtZQmqAfMjYlibr+6Ak/4iL3Q1oiV0XmCdDRAs4dxn2oYy8
0wxUtyGVxsGN8U6hyuyIP1GbrA/a4RJXf2dF7/mZnP3AfrTZJmfTUgTgeC2u1kAj
vv13S4kg8hgm+2VzKsgHisPz10F+LvkAwXrdAEQPNSVmE7Fy9kkXjEnmSnpi/RvH
LKGZGvB+kXMJnjZdz2HvD4Tgvxz9cCB7/jXfsycj1bZtyWUUU7xQvoGkvjgS6/LG
hXAfgXWDTEraIrkCmZPb2Ru1rriSjxYdWJAdsFPh64bS+0VBzhuooyyt6Ic1u3hT
Gid48dH36++gG8ZzaZfN3RbpJgZX951xUzePKQdk8IGmwbQG4yihTqJIyBsxaP71
pAp0GSmH38SgTyQb84zwObpQXChxBCOhAMCtjtA5wWEoTbU5AYWNl2NIegOpaFzj
YhsXff41pWC7TZIAuM0mXgCZEQoKi3D2lMWCMMbfS5Ky/cKMDx2vg2ZWGtihTjpN
qdkqhz3TPIJ75SLecDndco4TUp///g3Y13mCdfETRBSyO7JLXIxorm+FSF5/D8uX
6clY6ac9beSNDfGPsumf
=wcSZ
-----END PGP SIGNATURE-----

From martin.thomson@gmail.com  Fri Dec 13 17:05:28 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1631AE21C; Fri, 13 Dec 2013 17:05:28 -0800 (PST)
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 ZtkAKJJGXOGV; Fri, 13 Dec 2013 17:05:24 -0800 (PST)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 397DB1AE20F; Fri, 13 Dec 2013 17:05:24 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id q58so2618367wes.30 for ; Fri, 13 Dec 2013 17:05:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qKcywxxuv9zzlhxZ5X7lgUfRNWp3PP+NU7Xbu6MTvBo=; b=xutAiF0ejznfNXs0zi59Ht2UEF73xXdoBuBW2Dz6Rh+F6/yJZ92zWExJtAABoLnp0K Jz1YmMG67Kj/2HiLVNvdvqaqOT2AJ58cIrFU4ic7ZxQUxGr/f2xsizqIxgoqZyX3YuOW /4J6rIGIBUXWoW8jxU758z3TYsgyqqHCufO2sdxt1RjBlqT4wYnNhzTifU2CJn7XGIZH D8mBD8iw26aIRtZjc+NTQHXGT8f9yGlvuS0eUQrtk5v7oTOEjLXvo55H4mKUSmKwngDc kJsg13DNG+xSEL+A14Guqclsd34tjWS7/qzYrhRq2irYolMlfq19SsCHm4YcpkKvy32v pZZA==
MIME-Version: 1.0
X-Received: by 10.180.36.105 with SMTP id p9mr4939682wij.58.1386983117392; Fri, 13 Dec 2013 17:05:17 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Fri, 13 Dec 2013 17:05:17 -0800 (PST)
In-Reply-To: <52ABAB5E.4040506@akr.io>
References: <20131213171608.10285.15352.idtracker@ietfa.amsl.com> <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org> <52AB6323.2050107@akr.io>  <52ABAB5E.4040506@akr.io>
Date: Fri, 13 Dec 2013 17:05:17 -0800
Message-ID: 
From: Martin Thomson 
To: Alyssa Rowan 
Content-Type: text/plain; charset=UTF-8
Cc: The IESG , "ietf@ietf.org" , "tls@ietf.org" 
Subject: Re: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 14 Dec 2013 01:05:28 -0000

On 13 December 2013 16:50, Alyssa Rowan  wrote:
> It is, as you say, rushed. It looks
> like railroading, and I'm sure all want to avoid that appearance.

I don't agree with the characterization.  This needs to be fast, but
to say that is has been rushed would be a vast overstatement.  This
was first raised prior to the first individual submission of ALPN,
which was over a year ago.  We've talked about it a fair bit already
and I don't believe that the substance of more recent revelations
change anything.

I believe that our esteemed chairs and area directors have allowed
these concerns to be raised and debated sufficiently.  I am grateful
that, in this case, they have curtailed the right of infinite appeal
by closing this issue.

Me, I'd rather be spending my time dealing with TLS 1.3.  These
discussions aren't doing anyone a favour.

From nmav@redhat.com  Sat Dec 14 04:48:28 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097BB1ADFCF; Sat, 14 Dec 2013 04:48:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 r-cpZ5Lx34yA; Sat, 14 Dec 2013 04:47:52 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 63D421AD66E; Sat, 14 Dec 2013 04:47:52 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBEClhtb017186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Dec 2013 07:47:43 -0500
Received: from [10.10.48.254] (vpn-48-254.rdu2.redhat.com [10.10.48.254]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBECle9x028181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Dec 2013 07:47:42 -0500
Message-ID: <1387025259.17660.17.camel@aspire.lan>
From: Nikos Mavrogiannopoulos 
To: Alyssa Rowan 
Date: Sat, 14 Dec 2013 13:47:39 +0100
In-Reply-To: <52ABAB5E.4040506@akr.io>
References: <20131213171608.10285.15352.idtracker@ietfa.amsl.com> <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org> <52AB6323.2050107@akr.io>  <52ABAB5E.4040506@akr.io>
Organization: Red Hat
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.23
Cc: iesg@ietf.org, ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 14 Dec 2013 12:48:28 -0000

On Sat, 2013-12-14 at 00:50 +0000, Alyssa Rowan wrote:

> > [...]we now have TLS tell us whether there's HTTP/1 or HTTP/2 
> > inside.
> The I-D doesn't seem to limit this to HTTP/1 or HTTP/2: it's a general
> extension, which suggests a general use case.
> 
> If HTTP/(1|2) is all it's really intended to be used for at this time,
> (your and Martin's response makes me think maybe it is), then perhaps
> we SHOULD only use it for that at this time.
> I think that would substantially weaken my objection. How would others
> feel about that?

I don't see any advantage in your proposal. Why restrict ALPN from
negotiating anything else than HTTP? Currently we _already_ select
protocols in the clear using different service ports. ALPN allows to
negotiate different service even if the port is fixed (e.g. 443). Why do
you think ALPN is worse than what we have already and shouldn't be
allowed to negotiate other services?

I understand however you'd prefer ALPN not be in the clear, but TLS does
_not_ offer any mechanism to conceal anything negotiated during the
handshake. NPN takes the greedy path and hacks the protocol to allow
concealing only the negotiated protocol (the two peers' identities are
still in the clear as well as any other negotiated information). If NPN
is accepted it would certainly make harder designing a clean method that
conceals _all_ negotiated information in next protocol revision (as it
would have to carry the NPN hack).

regards,
Nikos



From akr@akr.io  Sat Dec 14 12:35:49 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11CC1A1F78; Sat, 14 Dec 2013 12:35:49 -0800 (PST)
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 Y5zHjgQ3okum; Sat, 14 Dec 2013 12:35:30 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id B2A251A1F66; Sat, 14 Dec 2013 12:35:29 -0800 (PST)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id 8AFA760A73; Sat, 14 Dec 2013 20:35:21 +0000 (GMT)
Message-ID: <52ACC10B.6070005@akr.io>
Date: Sat, 14 Dec 2013 20:35:23 +0000
From: Alyssa Rowan 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tls@ietf.org, ietf@ietf.org, iesg@ietf.org
References: <20131213171608.10285.15352.idtracker@ietfa.amsl.com>	 <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org> <52AB6323.2050107@akr.io>	 	 <52ABAB5E.4040506@akr.io> <1387025259.17660.17.camel@aspire.lan>
In-Reply-To: <1387025259.17660.17.camel@aspire.lan>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 14 Dec 2013 20:35:50 -0000

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

On 14/12/2013 12:47, Nikos Mavrogiannopoulos wrote:

>> [Limiting ALPN to HTTP/(1|2)]

To clarify, I specifically propose (Security Considerations?):

  It is NOT RECOMMENDED for a client using ALPN in TLS 1.2 to identify
  supported protocols other than HTTP/1 or HTTP/2: signalling that
  other protocols are supported could reveal more fingerprinting,
  targeting or application metadata in plaintext than is desirable or
  necessary.

  This caveat does not apply if the ClientHello is protected from
  passive eavesdropping [as in a future version of TLS].

(Subject to argument, of course.)

> I don't see any advantage in your proposal. Why restrict ALPN from
>  negotiating anything else than HTTP?

Because:
• It minimises plaintext fingerprinting.
  - Eve trivially knows every protocol Alice advertises support for.
  - Ideal if Eve wants to become Mallory and has a tailored exploit
    for one of them.
    · Real scenario: QUANTUM, EGOTISTICAL GIRAFFE, etc
  - Please let's keep that to a minimum, while it's still plaintext.
• Why use ALPN (or NPN!) for anything?
  - Why _indeed_ not use a port number? POP3 got one. Why not HTTP2?
  - Because of port-blocking firewalls disallowing all but port 80/443.
  - Many non-IETF protocol deployments bitten by this chose to use 443.
    · Tor
    · Several VPNs, including SSTP, and commonly OpenVPN in the wild
    · Skype [not that that's a _good_ protocol, just a common one!]
  - So multiplexing on 443 is considered fairly commonplace/desirable.
  - But DPI firewalls, even simple ones, can read ALPN if plaintext.
    · So they'd block those, too. Then what? Stop using ALPN? Lie in it?
• Most of all, because: it's HTTP/2 that needs it _right now_.
  - Other things can have it later, in TLS 1.3, when it's much safer.

At this point (post-IETF 88) if we were redesigning UDP or TCP, we'd
certainly consider encrypting the port numbers, if it were practical,
wouldn't we?

As far as your point that NPN is a bit of a hack, I agree.


It may be better to have ALPN in a limited fashion now, so that Martin
and the httpbis WG can proceed - I do not really want to delay their
fine work - and encrypt the whole ClientHello later in TLS 1.3.

Therefore, upon reconsideration, I withdraw my objection to ALPN
progressing to Proposed Standard.

I do wish for my caveat above to be noted under Security
Considerations, although this is of course subject to argument,
as others may not agree.

I apologise for any inconvenience caused.

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

iQIcBAEBCgAGBQJSrMEKAAoJEOyEjtkWi2t6JIcP/2UuGi+sg0dAKOnzBjzpxwo0
CvgVwES4WtF2QJEq7sCkXbYUIqW4uDeNAUy6D+vR5+Q407oPeIgR4IH9AzThFkpM
MR6cBP+yYyRpr0AFCtuupR77L0up9uLoSZxAgH7A4ot6s/fa2Vg1xtxE+C5/Sz4G
lPc6j8Rr3LnWlqH47kp+YxZAtAOa2pieWYDJlS8zK2Ulaf7I1mtAIy4MDAVrFYAN
Tye/LQLg485j0uXiDs3xErps0XJQKTT+dV3WtPMyNek6XjEQgHXQ9WbJE9t6F8W0
9Y5b2gzhoPoJ99OYTvZmYtdPdtFHHU+Hq6Q4ZuP64AMFviNTY7TQl3PD68WIiCyy
7feWHtl7Zb0Cbx8l+ZN3OV8BuUIcO3StcFnjaIu0jPP+Th2Wf9I+6045uqBq/Gmw
VmpMVR7+QDBLt15VnIuZNwdbo+e7Apin/YNnWxKg6PYakYXtCqQv+xWiexZooNn9
9vRnn3dzfLYMyjjd4sPDiEQ0toMIOQ133IToN6/TRU+VX00BnX5mZ8IMvRTwoVXz
ja1NJJUnZrYkS4P6/knR/8pQBONtVbQQ/JFhbmH2KtaUWdG4KnE9RSzCe3FVC9Um
iHeC/uY6ZTM521ISfCOH2+hj6Z3BDPm8WZCdLHB6T2pg+7ki+g8SbvpnaPy5RQ1L
N4TGPOysvUqmgcm9EDjT
=F2Gq
-----END PGP SIGNATURE-----

From ynir@checkpoint.com  Sat Dec 14 13:40:30 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5F11AD8DB; Sat, 14 Dec 2013 13:40:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level: 
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 5WX7RJtBo-QY; Sat, 14 Dec 2013 13:40:24 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0392D1AD73E; Sat, 14 Dec 2013 13:40:23 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rBELeESf013110; Sat, 14 Dec 2013 23:40:14 +0200
X-CheckPoint: {52ACCC81-2-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.146]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Sat, 14 Dec 2013 23:40:14 +0200
From: Yoav Nir 
To: Alyssa Rowan 
Thread-Topic: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
Thread-Index: AQHO+DuLUg8FUfdLCEiXwUM7nt4jjppShqYAgAA0XgCAAMhVgIAAgq+AgAASG4A=
Date: Sat, 14 Dec 2013 21:40:13 +0000
Message-ID: 
References: <20131213171608.10285.15352.idtracker@ietfa.amsl.com> <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org> <52AB6323.2050107@akr.io>  <52ABAB5E.4040506@akr.io> <1387025259.17660.17.camel@aspire.lan> <52ACC10B.6070005@akr.io>
In-Reply-To: <52ACC10B.6070005@akr.io>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.65]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <05EC9A7B8F0FB840A21445534DCC7342@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" , "" , "" 
Subject: Re: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 14 Dec 2013 21:40:31 -0000

On Dec 14, 2013, at 10:35 PM, Alyssa Rowan  wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>=20
> On 14/12/2013 12:47, Nikos Mavrogiannopoulos wrote:
>=20
>>> [Limiting ALPN to HTTP/(1|2)]
>=20
> To clarify, I specifically propose (Security Considerations?):
>=20
>  It is NOT RECOMMENDED for a client using ALPN in TLS 1.2 to identify
>  supported protocols other than HTTP/1 or HTTP/2: signalling that
>  other protocols are supported could reveal more fingerprinting,
>  targeting or application metadata in plaintext than is desirable or
>  necessary.
>=20
>  This caveat does not apply if the ClientHello is protected from
>  passive eavesdropping [as in a future version of TLS].
>=20
> (Subject to argument, of course.)

Someone here suggested running email protocols (IMAP, POP3, and SMTP) over =
the same 443 port, distinguished by ALPN. In sites such as live.com or mail=
.google.com, you might even get the same information in HTTP/1, HTTP/2, IMA=
P, or POP3. Why should those be excluded?  How about having this in the sec=
urity considerations:

   Implementers and document editors who intend to extend the protocol=20
   identifier registry by adding new protocol identifiers should consider
   that in TLS versions 1.2 and below the client sends these identifiers
   in the clear, and should also consider that for at least the next=20
   decade, it is expected that browsers would normally use these earlier
   versions of TLS in the initial ClientHello.

   Care must be taken when such identifiers may leak personally=20
   identifiable information, or when such leakage may lead to profiling,
   or to leaking of sensitive information. If any of these apply to=20
   this new protocol identifier, the extension SHOULD NOT be used in TLS
   versions 1.2 and below, and documents specifying such protocol=20
   identifiers SHOULD recommend against such unsafe use.=20

>=20
>> I don't see any advantage in your proposal. Why restrict ALPN from
>> negotiating anything else than HTTP?
>=20
> Because:
> =95 It minimises plaintext fingerprinting.
>  - Eve trivially knows every protocol Alice advertises support for.
>  - Ideal if Eve wants to become Mallory and has a tailored exploit
>    for one of them.
>    =B7 Real scenario: QUANTUM, EGOTISTICAL GIRAFFE, etc
>  - Please let's keep that to a minimum, while it's still plaintext.
> =95 Why use ALPN (or NPN!) for anything?
>  - Why _indeed_ not use a port number? POP3 got one. Why not HTTP2?
>  - Because of port-blocking firewalls disallowing all but port 80/443.
>  - Many non-IETF protocol deployments bitten by this chose to use 443.
>    =B7 Tor
>    =B7 Several VPNs, including SSTP, and commonly OpenVPN in the wild
>    =B7 Skype [not that that's a _good_ protocol, just a common one!]
>  - So multiplexing on 443 is considered fairly commonplace/desirable.
>  - But DPI firewalls, even simple ones, can read ALPN if plaintext.
>    =B7 So they'd block those, too. Then what? Stop using ALPN? Lie in it?
> =95 Most of all, because: it's HTTP/2 that needs it _right now_.
>  - Other things can have it later, in TLS 1.3, when it's much safer.
>=20
> At this point (post-IETF 88) if we were redesigning UDP or TCP, we'd
> certainly consider encrypting the port numbers, if it were practical,
> wouldn't we?
>=20
> As far as your point that NPN is a bit of a hack, I agree.
>=20
>=20
> It may be better to have ALPN in a limited fashion now, so that Martin
> and the httpbis WG can proceed - I do not really want to delay their
> fine work - and encrypt the whole ClientHello later in TLS 1.3.
>=20
> Therefore, upon reconsideration, I withdraw my objection to ALPN
> progressing to Proposed Standard.
>=20
> I do wish for my caveat above to be noted under Security
> Considerations, although this is of course subject to argument,
> as others may not agree.
>=20
> I apologise for any inconvenience caused.
>=20
> - --=20
> /akr
> -----BEGIN PGP SIGNATURE-----
>=20
> iQIcBAEBCgAGBQJSrMEKAAoJEOyEjtkWi2t6JIcP/2UuGi+sg0dAKOnzBjzpxwo0
> CvgVwES4WtF2QJEq7sCkXbYUIqW4uDeNAUy6D+vR5+Q407oPeIgR4IH9AzThFkpM
> MR6cBP+yYyRpr0AFCtuupR77L0up9uLoSZxAgH7A4ot6s/fa2Vg1xtxE+C5/Sz4G
> lPc6j8Rr3LnWlqH47kp+YxZAtAOa2pieWYDJlS8zK2Ulaf7I1mtAIy4MDAVrFYAN
> Tye/LQLg485j0uXiDs3xErps0XJQKTT+dV3WtPMyNek6XjEQgHXQ9WbJE9t6F8W0
> 9Y5b2gzhoPoJ99OYTvZmYtdPdtFHHU+Hq6Q4ZuP64AMFviNTY7TQl3PD68WIiCyy
> 7feWHtl7Zb0Cbx8l+ZN3OV8BuUIcO3StcFnjaIu0jPP+Th2Wf9I+6045uqBq/Gmw
> VmpMVR7+QDBLt15VnIuZNwdbo+e7Apin/YNnWxKg6PYakYXtCqQv+xWiexZooNn9
> 9vRnn3dzfLYMyjjd4sPDiEQ0toMIOQ133IToN6/TRU+VX00BnX5mZ8IMvRTwoVXz
> ja1NJJUnZrYkS4P6/knR/8pQBONtVbQQ/JFhbmH2KtaUWdG4KnE9RSzCe3FVC9Um
> iHeC/uY6ZTM521ISfCOH2+hj6Z3BDPm8WZCdLHB6T2pg+7ki+g8SbvpnaPy5RQ1L
> N4TGPOysvUqmgcm9EDjT
> =3DF2Gq
> -----END PGP SIGNATURE-----
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From akr@akr.io  Sat Dec 14 15:24:19 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F6A1AD694; Sat, 14 Dec 2013 15:24:19 -0800 (PST)
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 IeCsGO-eUjMX; Sat, 14 Dec 2013 15:24:15 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id A6D7C1ADEDC; Sat, 14 Dec 2013 14:53:02 -0800 (PST)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id C760B60A73; Sat, 14 Dec 2013 22:52:54 +0000 (GMT)
Message-ID: <52ACE148.7060209@akr.io>
Date: Sat, 14 Dec 2013 22:52:56 +0000
From: Alyssa Rowan 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tls@ietf.org, ietf@ietf.org
References: <20131213171608.10285.15352.idtracker@ietfa.amsl.com>	 <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org> <52AB6323.2050107@akr.io>	 	 <52ABAB5E.4040506@akr.io> <1387025259.17660.17.camel@aspire.lan> <52ACC10B.6070005@akr.io> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 14 Dec 2013 23:24:20 -0000
X-List-Received-Date: Sat, 14 Dec 2013 23:24:20 -0000

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

On 14/12/2013 21:40, Yoav Nir wrote:

> How about having this in the security considerations:
> 
> Implementers and document editors who intend to extend the
> protocol identifier registry by adding new protocol identifiers
> should consider that in TLS versions 1.2 and below the client sends
> these identifiers in the clear, and should also consider that for
> at least the next decade, it is expected that browsers would
> normally use these earlier versions of TLS in the initial
> ClientHello.
> 
> Care must be taken when such identifiers may leak personally 
> identifiable information, or when such leakage may lead to 
> profiling, or to leaking of sensitive information. If any of these 
> apply to this new protocol identifier, the extension SHOULD NOT be 
> used in TLS versions 1.2 and below, and documents specifying such 
> protocol identifiers SHOULD recommend against such unsafe use.

Absolutely. Much better than my wording. Less limiting, but lets them
know what they're doing by using it.

The next decade part makes me a sad panda. Realistic, but depressing.
Let's see if we can do better with TLS 1.3!

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

iQIcBAEBCgAGBQJSrOFIAAoJEOyEjtkWi2t6P5IQAKTevPpoom8Op0BX6NZeDvPR
FBQ/z7IGHy4e33hb0nI8ucTaei3TAfwwdJcbt4i+Kn5L9zfN2WqOkTKQxxN+lFWL
lZkqhNcmVjlPo+Udui9LLd7duaeNWjJ4Mm2rhWh8vKyJ4YgQM0Y0h36Tb6RGQDKG
yKrDsXSJcnxK69vm6YvIDxv5uJ0M/okAKoxe7osEtIjCHsfGvn2aDppOYWbClD38
eXQKdFeBm5+mvFid5VAmjuyV0Qk6mht3Nuhn6D2uR7qfuvV5MpJR83Ne7yZNBNXY
TG1YzCLHR4I+SLq4517Y++g0VK1IE4ozqNDOj2Ij/YCEvJ9d8S+p/IEBvkVmvMPq
66LtrwuhFAkkXj1Stv5CjqIJA+zQB8jZ7SjJEZ0FIEGbKFyeK9pGSh/zYgQzzJii
a26SojIuFqalE0luGH5NJLByOJ2EWAyC7G3CF9qDMqQ87LYZVGcvS8VO7w3IE2Bl
m1nKeZwhkk9ymztWNrNC3DEEkski2tYODsA/glPP5aMp/2B9ggfKQXPJ0mRx1cEA
evzAZllaLYaf9j7F9KMOZj07ofHG6bWU4Q2hNArp131QbqD7xPsqyH0kdvr2JSpa
3cwrPr5Put/9Ph/eAva9/gUyIYzdDPN3eEcRdew7tcd8YxC4MGEtp5dPrN+f+SLd
1qb5J2j+7FpBEfIW3KiK
=FfBO
-----END PGP SIGNATURE-----

From mbadra@gmail.com  Sat Dec 14 16:41:24 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5446E1ADF94 for ; Sat, 14 Dec 2013 16:41:24 -0800 (PST)
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 w8H2U102XbFu for ; Sat, 14 Dec 2013 16:41:20 -0800 (PST)
Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id D33941ADF7B for ; Sat, 14 Dec 2013 16:41:19 -0800 (PST)
Received: by mail-vb0-f41.google.com with SMTP id p14so657757vbm.14 for ; Sat, 14 Dec 2013 16:41:12 -0800 (PST)
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=MLqxyKndeg4XbgYDZIJKWUoveGsXpicpyQ1LCZrKFsw=; b=VBM6tZtPhta0S2jYAmqsWg8pjCvp1YbiEAM4Vg/HYDAj/qXmUP8jpEeQWhB8DxY+Md R4rJKo3VngjucOd/g/g+H7HWE/hfzmhgwk2PcgChpVR55h1TiqT7BxosVs2JeivvCwqp yjeCNLUEXxVGu8mlL4ufC9OEo4vUyniWTVyjHNWk72cQn5l/icT4BRZ7YxwVGfiWSDav YZZLYL/bo+/FcfMOTZQ7va22+4eVfJLmSPzxz5x8ibTwkCPdnETP0UwV9kYWUf6//uTz QOVya3EwvcrDPt8LfUjsxsbp7UPxCxrHj+spWproyfywIifK9W2KFzUr2uIZHCHw+rkL ENFQ==
MIME-Version: 1.0
X-Received: by 10.58.44.72 with SMTP id c8mr752787vem.37.1387068072849; Sat, 14 Dec 2013 16:41:12 -0800 (PST)
Received: by 10.220.165.132 with HTTP; Sat, 14 Dec 2013 16:41:12 -0800 (PST)
Date: Sun, 15 Dec 2013 04:41:12 +0400
Message-ID: 
From: Mohamad Badra 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=089e013cc1fcc2f92f04ed87f34e
Subject: [TLS] Passive TLS Clients - Reverse Connections
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 15 Dec 2013 00:41:24 -0000

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

Dear All,

I've submitted the following document to enable a TLS connection from a
server to a client after the initial handshake is complete.

Comments are welcome!
Best regards,
Badra

Filename:        draft-badra-tls-passive-client
Revision:        00
Title:           Passive Transport Layer Security (TLS) Clients
Creation date:   2013-12-15
Group:           Individual Submission
Number of pages: 3
URL:
http://www.ietf.org/internet-drafts/draft-badra-tls-passive-client-00.txt
Status:
http://datatracker.ietf.org/doc/draft-badra-tls-passive-client
Htmlized:
http://tools.ietf.org/html/draft-badra-tls-passive-client-00


Abstract:
   This document describes a technique for a Transport Layer Security
   (TLS) server to initiate a TLS connection to a TLS client.  This is
   accomplished by the TLS client listening on a port number sent from
   the client to the server during the initial TLS Handshake.  This
   document defines a TLS extension for conveying a port number from the
   client to the server.

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


Dear All,


I've submitted the following document to enable a TLS connection from a=
 server to a client after the initial handshake is complete.



Comments are welcome!
Best regards,

Badra



Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-badra-tls-passive-client

Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000

Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Passive Transport Layer Security =
(TLS) Clients

Creation date: =C2=A0 2013-12-15

Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission

Number of pages: 3

URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-badra-tls-passive-client-00.txt<=
/a>

Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatrac=
ker.ietf.org/doc/draft-badra-tls-passive-client

Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/=
html/draft-badra-tls-passive-client-00





Abstract:

=C2=A0 =C2=A0This document describes a technique for a Transport Layer Secu=
rity

=C2=A0 =C2=A0(TLS) server to initiate a TLS connection to a TLS client. =C2=
=A0This is

=C2=A0 =C2=A0accomplished by the TLS client listening on a port number sent=
 from

=C2=A0 =C2=A0the client to the server during the initial TLS Handshake. =C2=
=A0This

=C2=A0 =C2=A0document defines a TLS extension for conveying a port number f=
rom the

=C2=A0 =C2=A0client to the server.


--089e013cc1fcc2f92f04ed87f34e--

From watsonbladd@gmail.com  Sat Dec 14 16:48:11 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A00A1ADF56 for ; Sat, 14 Dec 2013 16:48:11 -0800 (PST)
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 MhW0_-SRtpYj for ; Sat, 14 Dec 2013 16:48:02 -0800 (PST)
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 1BF5E1ADF7B for ; Sat, 14 Dec 2013 16:48:01 -0800 (PST)
Received: by mail-wi0-f175.google.com with SMTP id hi5so755556wib.2 for ; Sat, 14 Dec 2013 16:47:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aEtloKEv3puU2mfHEBRpgENKwZ584c/TIGuX4uhrddE=; b=XGbUKZq8JwR9g2vmrIKepa9ZuKgC1unaCfztXuotOWINghPzVabrVh4LjE/pHpaJzP M3TsDkgcZSwMdoutrCcVYeQ+8uW2i3AfDSEugYAPUGmKxdw/AZJ50ZS2CcbAfUHgN810 oAdCUowx0bw3AXbtNR8nZYiR7zGpFHEtqFbvsH3tO6DCj7klhDo0CvXGh8wWEX4BZipq fW2uYrrtejHK5EY4f62hu7y2tueYWBMZaltrahv2jzEabe8YpOjvbKErOpqjjGDY9ikQ YRiZDUC0aGbLuSqT7XapldHyy2iODGwcya7MKlFTyEfiwYjFEOLt36pAYYNvLNwRFLqo eRSw==
MIME-Version: 1.0
X-Received: by 10.194.85.75 with SMTP id f11mr8076074wjz.14.1387068473806; Sat, 14 Dec 2013 16:47:53 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Sat, 14 Dec 2013 16:47:53 -0800 (PST)
In-Reply-To: 
References: 
Date: Sat, 14 Dec 2013 16:47:53 -0800
Message-ID: 
From: Watson Ladd 
To: Mohamad Badra 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Passive TLS Clients - Reverse Connections
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 15 Dec 2013 00:48:11 -0000

On Sat, Dec 14, 2013 at 4:41 PM, Mohamad Badra  wrote:
> Dear All,
>
> I've submitted the following document to enable a TLS connection from a
> server to a client after the initial handshake is complete.
Do you have a use case for this? Because once the handshake finishes
you have a perfectly good connection.
If an application protocol requires this, it can do it at the application level.
Sincerely,
Watson Ladd

From mbadra@gmail.com  Sun Dec 15 01:33:49 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A609B1AD8F1 for ; Sun, 15 Dec 2013 01:33:49 -0800 (PST)
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 SdcEKfxef1li for ; Sun, 15 Dec 2013 01:33:44 -0800 (PST)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0A91AD68D for ; Sun, 15 Dec 2013 01:33:44 -0800 (PST)
Received: by mail-vc0-f175.google.com with SMTP id ld13so2394067vcb.20 for ; Sun, 15 Dec 2013 01:33:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k6PqU4ZnzcNYX/CdXERhDpkPw9OyLHqjOWK38qbFs8k=; b=kW8f38sk96ooFXcnEgcbn9Z6BYmY7QMQdgtbTJjQIFEk2RSXLKxFvWxyEo8vtUtOM6 KPubPmuQInajizzV2eZkUm8pKLRcqfJ2l/AuGaUVxPsaj17yRPzuibzrC2UmtwZB9Irh JabZtN+yGjWOndUZxIGX3YE+vJ1Ebmi8RV68zdDvWxcTBZxsM5Ws03rjhX/69rQ5bUdl Tu7AsGp7tYE9RwbWp3haGB7eh3fBG+dG13dlKMj7kwaMrvuccp8nxPh0b4FoaoKLbOs9 2hzMrrLKNBxIZlLyNdBhsoH4y9UnlRKr5qbbJBGWFRJlgtDh4ONrMX7Je3zmyPcMP8kA RBLg==
MIME-Version: 1.0
X-Received: by 10.52.162.168 with SMTP id yb8mr4934384vdb.8.1387100017082; Sun, 15 Dec 2013 01:33:37 -0800 (PST)
Received: by 10.220.165.132 with HTTP; Sun, 15 Dec 2013 01:33:36 -0800 (PST)
In-Reply-To: 
References:  
Date: Sun, 15 Dec 2013 13:33:36 +0400
Message-ID: 
From: Mohamad Badra 
To: Watson Ladd 
Content-Type: multipart/alternative; boundary=089e01634f1cc947a504ed8f63ad
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Passive TLS Clients - Reverse Connections
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 15 Dec 2013 09:33:49 -0000

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

On Sun, Dec 15, 2013 at 4:47 AM, Watson Ladd  wrote:

> On Sat, Dec 14, 2013 at 4:41 PM, Mohamad Badra  wrote:
> > Dear All,
> >
> > I've submitted the following document to enable a TLS connection from a
> > server to a client after the initial handshake is complete.
> Do you have a use case for this? Because once the handshake finishes
> you have a perfectly good connection.
> If an application protocol requires this, it can do it at the application
> level.
> Sincerely,
> Watson Ladd
>

=E2=80=8B=E2=80=8BI don't have an exhaustive list of scenarios where this e=
xtension could
be useful:

=E2=80=8B- Some of the applicative resources may be hosted behind a proxy o=
r a
firewall that implements NAT for the internal network IP addresses. They
may be hosted on devices in stealth mode or with dynamic IP addresses so
mapping between the resources and IP is not efficient.

- It is suitable for network management protocols such as NETCONF(*). It
will be easier to extend TLS than revising every application to enable
reverse connection over TLS And assign a new port number.

- In the case of reverse connections, it would be more secure to
configure your server (it may be easier to secure one open port than to
having an open port on each server in the network).

(*) Other benefits related to device management may be found at
http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-02#section-3.

Best regards,
Badra

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


On Sun, Dec 15, 2013 =
at 4:47 AM, Watson Ladd <watsonblad=
d@gmail.com> wrote:<=
br>


On Sat, Dec 14, 2013 at 4:41 PM, Mohamad Badra <mbadra@gmail.com> wrote:

> Dear All,

>

> I've submitted the following document to enable a TLS connection f=
rom a

> server to a client after the initial handshake is complete.


Do you have a use case for this? Because once the handshake finishes<=
br>
you have a perfectly good connection.

If an application protocol requires this, it can do it at the application l=
evel.

Sincerely,

Watson Ladd

=E2=
=80=8B=E2=80=8BI don't have an exhaustive list of scenarios where this =
extension could


be=
 useful:



=E2=80=8B- Some o=
f the applicative resources may be hosted behind a proxy or a
firewall that implements NAT for the internal network =
IP addresses. They


may be hosted on devices in stealth mode or wi=
th dynamic IP addresses so
mapping betwee=
n the resources and IP is not efficient.


- It is suitable=
 for network management protocols such as NETCONF(*). It

will be easier to extend TLS th=
an revising every application to enable
reverse connection over T=
LS And assign a new port number.


- In the case of reverse connections, it would be more secure =
to


co=
nfigure your server (it may be easier to secure one open port than to
having an open port on each server in the network).=C2=A0



(*) Other benefits related to device m=
anagement may be found at
http://tools.ietf.org/html/draf=
t-ietf-netconf-reverse-ssh-02#section-3.


Best regards,
Badra




--089e01634f1cc947a504ed8f63ad--

From dol@cryptocom.ru  Sun Dec 15 00:36:03 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5591AE1D5; Sun, 15 Dec 2013 00:36:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.448
X-Spam-Level: **
X-Spam-Status: No, score=2.448 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_CHARSET_FARAWAY=2.45, 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 cx7jWDVpVovo; Sun, 15 Dec 2013 00:35:59 -0800 (PST)
Received: from mail.reedcat.net (mail.reedcat.net [85.17.92.214]) by ietfa.amsl.com (Postfix) with ESMTP id C0BF91AE1D7; Sun, 15 Dec 2013 00:35:59 -0800 (PST)
Received: from [192.168.63.8] (broadband-188-255-54-202.nationalcablenetworks.ru [188.255.54.202]) by mail.reedcat.net (Postfix) with ESMTPSA id 00E7D1A4927; Sun, 15 Dec 2013 12:35:50 +0400 (MSK)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=koi8-r
From: Basil Dolmatov 
X-Priority: 3 (Normal)
In-Reply-To: <8cf8a51b9dcfd0c40b80ae2aad2cff7c.squirrel@www.trepanning.net>
Date: Sun, 15 Dec 2013 12:35:49 +0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net>    <8cf8a51b9dcfd0c40b80ae2aad2cff7c.squirrel@www.trepanning.net>
To: Dan Harkins 
X-Mailer: Apple Mail (2.1822)
X-Mailman-Approved-At: Sun, 15 Dec 2013 16:07:15 -0800
Cc: cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org
Subject: Re: [TLS] [Cfrg]  [saag] Question regarding CFRG process
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 15 Dec 2013 08:36:03 -0000

Was impressed by the quality of arguments used in discussing of new =
cryptographic protocols. :-/

dol@


13 =C4=C5=CB. 2013 =C7., =D7 12:35, Dan Harkins  =
=CE=C1=D0=C9=D3=C1=CC(=C1):

>=20
>=20
>  You obviously read too much fiction and have too little practical
> experience. Dragonfly is not a threat to human life. Get a grip.
>=20
...
>  I'm also familiar with well-respected cryptographers who participated
> in the IPsec WG in the 90s. You are nobody compared to them and your
> ignorant reference confirms that.
>=20
>>>>>=20
>=20
>  Dan.
>=20
>=20
>=20
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>=20


From randy_presuhn@mindspring.com  Sun Dec 15 16:03:07 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33121AE224; Sun, 15 Dec 2013 16:03:06 -0800 (PST)
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, 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 19mjTtw3ZUnn; Sun, 15 Dec 2013 16:03:04 -0800 (PST)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 10F141AE20B; Sun, 15 Dec 2013 16:03:03 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Hyx125S3hjNCmv+fk3PkmacYv55hMwpT1Y8YY8MPG2WrV+6RJzw1YgS3rLmNp3N6; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [76.254.54.154] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VsLeI-000553-Vq; Sun, 15 Dec 2013 19:03:03 -0500
Message-ID: <006a01cef9f2$6e59bde0$6b01a8c0@oemcomputer>
From: "Randy Presuhn" 
To: , , 
References: <20131213171608.10285.15352.idtracker@ietfa.amsl.com> <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org> <52AB6323.2050107@akr.io>  <52ABAB5E.4040506@akr.io>
Date: Sun, 15 Dec 2013 16:04:45 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb95d58d56dff202c4c06c0644a1c6d2c7350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 76.254.54.154
X-Mailman-Approved-At: Sun, 15 Dec 2013 16:07:15 -0800
Subject: Re: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 16 Dec 2013 00:03:07 -0000

Hi -

> From: "Alyssa Rowan" 
> To: ; ; 
> Sent: Friday, December 13, 2013 4:50 PM
> Subject: Re: [TLS] Last Call:  (Transport Layer Security (TLS) Application Layer Protocol
Negotiation Extension) to Proposed Standard
...
> If HTTP/(1|2) is all it's really intended to be used for at this time,
> (your and Martin's response makes me think maybe it is), then perhaps
> we SHOULD only use it for that at this time.
>
> I think that would substantially weaken my objection. How would others
> feel about that?

I think at least a little consideration should be given to other
protocols that employ TLS, e.g. Netconf.

Randy



From jsalowey@cisco.com  Mon Dec 16 08:40:33 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF1F1AE2F5 for ; Mon, 16 Dec 2013 08:40:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.039
X-Spam-Level: 
X-Spam-Status: No, score=-15.039 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.538, 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 415gjBnB_tes for ; Mon, 16 Dec 2013 08:40:32 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B12161AE07E for ; Mon, 16 Dec 2013 08:40:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=317; q=dns/txt; s=iport; t=1387212032; x=1388421632; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=EgTrRnCcwO+s/CNAm3G6TDgXhOSc6V4/D2SzSzzPIfU=; b=g5EKqG9pWdvKj4uFN1+n+jp6YyA0LCFwHvAtRrioYat7C94KLpZkc+e3 2ItV3U32PTvlhLenMYUxBSz7qDZoXXKTIU+zMxvgTutsH3wwAOpncy9MR uUll/cvQLuR2dkEiVOfZ6LJl1VRo85KhNbX0ncISVWWFMlyKAqh3rm5a+ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFADssr1KtJXHB/2dsb2JhbABZgwqBDaZxkyYWdIIsOlEBPkInBIgXoHmnMReSQ4ETBJgWkhSDKoIq
X-IronPort-AV: E=Sophos;i="4.95,495,1384300800"; d="scan'208";a="291925569"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 16 Dec 2013 16:40:32 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBGGeVYL013652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Dec 2013 16:40:32 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 10:40:31 -0600
From: "Joseph Salowey (jsalowey)" 
To: "" 
Thread-Topic: Conclusion of WGLC draft-ietf-tls-pwd
Thread-Index: AQHO+n2ITE7ZrDiamkK2ti5CZ6kIZg==
Date: Mon, 16 Dec 2013 16:40:31 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.92.217]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4484E585A593C84E8DF04EBC1055543F@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [TLS] Conclusion of WGLC draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 16 Dec 2013 16:40:33 -0000

The WGLC for draft-ietf-tls-pwd has concluded.  The WGLC did not result in =
consensus to move the document forward.  We have discussed this with the Ar=
ea Director and given that the working group has more pressing issues we wi=
ll not be continuing this work at this time.

Thanks,

Joe
[For the chairs]=

From maray@microsoft.com  Mon Dec 16 19:33:52 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB741AE063 for ; Mon, 16 Dec 2013 19:33:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.087
X-Spam-Level: 
X-Spam-Status: No, score=-1.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 4b61qAouJMuE for ; Mon, 16 Dec 2013 19:33:50 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0155.outbound.protection.outlook.com [207.46.163.155]) by ietfa.amsl.com (Postfix) with ESMTP id 19A3D1AE004 for ; Mon, 16 Dec 2013 19:33:49 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB073.namprd03.prod.outlook.com (10.255.241.153) with Microsoft SMTP Server (TLS) id 15.0.842.7; Tue, 17 Dec 2013 03:33:47 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.137]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.137]) with mapi id 15.00.0842.003; Tue, 17 Dec 2013 03:33:46 +0000
From: Marsh Ray 
To: Watson Ladd , "Salz, Rich" 
Thread-Topic: [TLS] TLS Charter Revision
Thread-Index: AQHO75QH12xj16hlv0SmAgrMfgWOIZpB1QcAgAF+I3CADT1cAIAALz4AgAAHaYCAALekAIAAC32AgAZA8MA=
Date: Tue, 17 Dec 2013 03:33:45 +0000
Message-ID: <568e68cbc61344fc8ad91dcd238a5f4b@BY2PR03MB074.namprd03.prod.outlook.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>  <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com> <3A9A4169-6B5E-453E-930A-F00291B541F4@apple.com>  <2A0EFB9C05D0164E98F19BB0AF3708C711E4675283@USMBX1.msg.corp.akamai.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: 006339698F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(377454003)(199002)(189002)(51704005)(15975445006)(53806001)(54356001)(81542001)(50986001)(2656002)(81816001)(81686001)(74662001)(83322001)(19580395003)(51856001)(56816005)(85306002)(69226001)(81342001)(87936001)(76796001)(76786001)(46102001)(74366001)(80976001)(74706001)(74316001)(47736001)(87266001)(47976001)(4396001)(76482001)(83072002)(63696002)(31966008)(74502001)(47446002)(74876001)(15202345003)(85852003)(80022001)(59766001)(65816001)(76576001)(33646001)(49866001)(77096001)(79102001)(77982001)(561944002)(54316002)(56776001)(90146001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB073; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "" 
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 17 Dec 2013 03:33:52 -0000

RnJvbTogVExTIE9uIEJlaGFsZiBPZiBXYXRzb24gTGFkZA0KU2VudDogVGh1cnNkYXksIERlY2Vt
YmVyIDEyLCAyMDEzIDc6MzggUE0NCj4NCj4gVExTIGNvdWxkIGJlIG9uZSByb3VuZCB0cmlwIGlm
IHdlIHdlcmUgd2lsbGluZyB0byBlbGltaW5hdGUgYSBidW5jaA0KPiBvZiBvcHRpb25zLiBJIHRo
aW5rIHdlIHNob3VsZCBoYXZlIGEgZGlzY3Vzc2lvbiBhaW1lZCBhdCBzZWVpbmcgd2hhdA0KPiB3
ZSBjYW4gY2hvcCBvdXQgdG8gcmVkdWNlIHRoZSBuZWVkIGZvciBuZWdvdGlhdGlvbi4NCg0KSSB0
aGluayBtb3N0IG9mIHVzIHdvdWxkIGFncmVlIHRoYXQgdGhlIGFiaWxpdHkgdG8gdXNlIGZvcndh
cmQtc2VjcmV0DQprZXkgZXhjaGFuZ2UgcmVtYWlucyBhIHJlcXVpcmVtZW50Lg0KDQpJbiB0aGVz
ZSBkaXNjdXNzaW9ucyBJIGFtIG9mdGVuIHJlbWluZGVkIG9mIHRoaXMgZWFybGllciBwcm9wb3Nh
bA0Kd2hpY2ggYXR0ZW1wdGVkIHNvbWUgb2YgdGhlc2UgZGVzaWduIGNoYWxsZW5nZXM6DQpodHRw
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hZ2wtdGxzLXNuYXBzdGFydC0wMCNzZWN0aW9u
LTINCg0KLSBNYXJzaA0KIA0K

From maray@microsoft.com  Mon Dec 16 21:39:46 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF191ADF44 for ; Mon, 16 Dec 2013 21:39:46 -0800 (PST)
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, HTML_MESSAGE=0.001, 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 ib0ELRNhz0He for ; Mon, 16 Dec 2013 21:39:43 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAD51ADF99 for ; Mon, 16 Dec 2013 21:39:43 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) with Microsoft SMTP Server (TLS) id 15.0.842.7; Tue, 17 Dec 2013 05:39:34 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.137]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.137]) with mapi id 15.00.0842.003; Tue, 17 Dec 2013 05:39:34 +0000
From: Marsh Ray 
To: Mohamad Badra , Watson Ladd 
Thread-Topic: [TLS] Passive TLS Clients - Reverse Connections
Thread-Index: AQHO+S5uUTwOSitRtUqUmvRBcpH27ppUbDWAgACS4wCAAuFhwA==
Date: Tue, 17 Dec 2013 05:39:33 +0000
Message-ID: <9b71054038a54d40b1f686497b3eb162@BY2PR03MB074.namprd03.prod.outlook.com>
References:   
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: 006339698F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(51704005)(377454003)(189002)(199002)(24454002)(80022001)(59766001)(74502001)(15202345003)(47446002)(19300405004)(85852003)(31966008)(77982001)(54316002)(56776001)(90146001)(79102001)(33646001)(74876001)(65816001)(76576001)(77096001)(49866001)(83072002)(76482001)(83322001)(19580395003)(63696002)(56816005)(51856001)(74662001)(69226001)(85306002)(53806001)(54356001)(16236675002)(15975445006)(81686001)(81816001)(19609705001)(74366001)(50986001)(2656002)(81542001)(80976001)(74316001)(74706001)(87266001)(19580405001)(47736001)(4396001)(76796001)(87936001)(81342001)(46102001)(47976001)(76786001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB074; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_9b71054038a54d40b1f686497b3eb162BY2PR03MB074namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Passive TLS Clients - Reverse Connections
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 17 Dec 2013 05:39:46 -0000

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

RnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNb2hh
bWFkIEJhZHJhDQo+IFNvbWUgb2YgdGhlIGFwcGxpY2F0aXZlIHJlc291cmNlcyBtYXkgYmUgaG9z
dGVkIGJlaGluZCBhIHByb3h5IG9yIGENCj4gZmlyZXdhbGwgdGhhdCBpbXBsZW1lbnRzIE5BVCBm
b3IgdGhlIGludGVybmFsIG5ldHdvcmsgSVAgYWRkcmVzc2VzLiBUaGV5DQo+IG1heSBiZSBob3N0
ZWQgb24gZGV2aWNlcyBpbiBzdGVhbHRoIG1vZGUgb3Igd2l0aCBkeW5hbWljIElQIGFkZHJlc3Nl
cyBzbw0KPiBtYXBwaW5nIGJldHdlZW4gdGhlIHJlc291cmNlcyBhbmQgSVAgaXMgbm90IGVmZmlj
aWVudC4NCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmFkcmEtdGxzLXBhc3Np
dmUtY2xpZW50LTAwIHNheXM6DQo+IE9uY2UgdGhlIGluaXRpYWwgaGFuZHNoYWtpbmcgaXMgY29t
cGxldGUsIHRoZSBzZXJ2ZXIgTUFZIGFjdGl2ZWx5DQo+IG9wZW4gYSBUQ1Agb3IgVURQIGNvbm5l
Y3Rpb24gdG8gdGhlIGNsaWVudCB1c2luZyB0aGUgcG9ydCBudW1iZXINCj4gcmVjZWl2ZWQgaW4g
dGhlIENsaWVudEhlbGxvLiAgT25jZSB0aGUgVENQIG9yIFVEUCBjb25uZWN0aW9uIGhhcyBiZWVu
DQo+IGVzdGFibGlzaGVkLCB0aGUgY2xpZW50IHRha2VzIGluaXRpYXRpdmUgYW5kIHNlbmRzIHRo
ZSBUTFMNCj4gQ2xpZW50SGVsbG8gbWVzc2FnZSB0byBiZWdpbiB0aGUgVExTIGFiYnJldmlhdGVk
IGhhbmRzaGFrZS4NCg0KU28gaWYgYW4gYXR0YWNrZXIgd2VyZSB0byBpbnRlcmNlcHQgdGhpcyBU
Q1AgY29ubmVjdGlvbiBjb21pbmcgZnJvbQ0KdGhlIGxlZ2l0aW1hdGUgc2VydmVyLCBjb3VsZG7i
gJl0IGhlIGp1c3Qgc2VuZCBhIENsaWVudEhlbGxvLCBlc3RhYmxpc2gNCmhpcyBvd24gc2Vzc2lv
biwgYW5kIHRodXMgbGVhcm4gd2hhdGV2ZXIgdGhlIGxlZ2l0aW1hdGUgc2VydmVyIGhhZA0KaW50
ZW5kZWQgdG8gc2F5IHRvIHRoZSBhcHBsaWNhdGl2ZSByZXNvdXJjZSBzZXJ2ZXIgYW5kIHBvc3Np
Ymx5IGV2ZW4NCmZvcmdlIGEgcmVzcG9uc2U/DQoNCg0KLSAgICAgICAgICBNYXJzaA0KDQpGcm9t
OiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1vaGFtYWQg
QmFkcmENClNlbnQ6IFN1bmRheSwgRGVjZW1iZXIgMTUsIDIwMTMgMTozNCBBTQ0KVG86IFdhdHNv
biBMYWRkDQpDYzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gUGFzc2l2ZSBUTFMg
Q2xpZW50cyAtIFJldmVyc2UgQ29ubmVjdGlvbnMNCg0KT24gU3VuLCBEZWMgMTUsIDIwMTMgYXQg
NDo0NyBBTSwgV2F0c29uIExhZGQgPHdhdHNvbmJsYWRkQGdtYWlsLmNvbTxtYWlsdG86d2F0c29u
YmxhZGRAZ21haWwuY29tPj4gd3JvdGU6DQpPbiBTYXQsIERlYyAxNCwgMjAxMyBhdCA0OjQxIFBN
LCBNb2hhbWFkIEJhZHJhIDxtYmFkcmFAZ21haWwuY29tPG1haWx0bzptYmFkcmFAZ21haWwuY29t
Pj4gd3JvdGU6DQo+IERlYXIgQWxsLA0KPg0KPiBJJ3ZlIHN1Ym1pdHRlZCB0aGUgZm9sbG93aW5n
IGRvY3VtZW50IHRvIGVuYWJsZSBhIFRMUyBjb25uZWN0aW9uIGZyb20gYQ0KPiBzZXJ2ZXIgdG8g
YSBjbGllbnQgYWZ0ZXIgdGhlIGluaXRpYWwgaGFuZHNoYWtlIGlzIGNvbXBsZXRlLg0KRG8geW91
IGhhdmUgYSB1c2UgY2FzZSBmb3IgdGhpcz8gQmVjYXVzZSBvbmNlIHRoZSBoYW5kc2hha2UgZmlu
aXNoZXMNCnlvdSBoYXZlIGEgcGVyZmVjdGx5IGdvb2QgY29ubmVjdGlvbi4NCklmIGFuIGFwcGxp
Y2F0aW9uIHByb3RvY29sIHJlcXVpcmVzIHRoaXMsIGl0IGNhbiBkbyBpdCBhdCB0aGUgYXBwbGlj
YXRpb24gbGV2ZWwuDQpTaW5jZXJlbHksDQpXYXRzb24gTGFkZA0KDQrigIvigItJIGRvbid0IGhh
dmUgYW4gZXhoYXVzdGl2ZSBsaXN0IG9mIHNjZW5hcmlvcyB3aGVyZSB0aGlzIGV4dGVuc2lvbiBj
b3VsZA0KYmUgdXNlZnVsOg0KDQrigIstIFNvbWUgb2YgdGhlIGFwcGxpY2F0aXZlIHJlc291cmNl
cyBtYXkgYmUgaG9zdGVkIGJlaGluZCBhIHByb3h5IG9yIGENCmZpcmV3YWxsIHRoYXQgaW1wbGVt
ZW50cyBOQVQgZm9yIHRoZSBpbnRlcm5hbCBuZXR3b3JrIElQIGFkZHJlc3Nlcy4gVGhleQ0KbWF5
IGJlIGhvc3RlZCBvbiBkZXZpY2VzIGluIHN0ZWFsdGggbW9kZSBvciB3aXRoIGR5bmFtaWMgSVAg
YWRkcmVzc2VzIHNvDQptYXBwaW5nIGJldHdlZW4gdGhlIHJlc291cmNlcyBhbmQgSVAgaXMgbm90
IGVmZmljaWVudC4NCg0KLSBJdCBpcyBzdWl0YWJsZSBmb3IgbmV0d29yayBtYW5hZ2VtZW50IHBy
b3RvY29scyBzdWNoIGFzIE5FVENPTkYoKikuIEl0DQp3aWxsIGJlIGVhc2llciB0byBleHRlbmQg
VExTIHRoYW4gcmV2aXNpbmcgZXZlcnkgYXBwbGljYXRpb24gdG8gZW5hYmxlDQpyZXZlcnNlIGNv
bm5lY3Rpb24gb3ZlciBUTFMgQW5kIGFzc2lnbiBhIG5ldyBwb3J0IG51bWJlci4NCg0KLSBJbiB0
aGUgY2FzZSBvZiByZXZlcnNlIGNvbm5lY3Rpb25zLCBpdCB3b3VsZCBiZSBtb3JlIHNlY3VyZSB0
bw0KY29uZmlndXJlIHlvdXIgc2VydmVyIChpdCBtYXkgYmUgZWFzaWVyIHRvIHNlY3VyZSBvbmUg
b3BlbiBwb3J0IHRoYW4gdG8NCmhhdmluZyBhbiBvcGVuIHBvcnQgb24gZWFjaCBzZXJ2ZXIgaW4g
dGhlIG5ldHdvcmspLg0KDQooKikgT3RoZXIgYmVuZWZpdHMgcmVsYXRlZCB0byBkZXZpY2UgbWFu
YWdlbWVudCBtYXkgYmUgZm91bmQgYXQNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWlldGYtbmV0Y29uZi1yZXZlcnNlLXNzaC0wMiNzZWN0aW9uLTMuDQoNCkJlc3QgcmVnYXJkcywN
CkJhZHJhDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N
c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw
aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp
Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l
cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN
Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y
dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp
biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp
c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjk3MTQwNjMyNjsNCglt
c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4NTU0MDQ2NTQg
OTQzMjA0ODU2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3
Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt
c3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28t
YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0
IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp
bmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m
YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg
bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt
ZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJn
aW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu
ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk
aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+
PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1
ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVExTIFttYWlsdG86dGxzLWJvdW5jZXNA
aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1vaGFtYWQgQmFkcmE8YnI+DQo8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgU29tZSBvZiB0
aGUgYXBwbGljYXRpdmUgcmVzb3VyY2VzIG1heSBiZSBob3N0ZWQgYmVoaW5kIGEgcHJveHkgb3Ig
YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7IGZpcmV3YWxsIHRoYXQgaW1wbGVt
ZW50cyBOQVQgZm9yIHRoZSBpbnRlcm5hbCBuZXR3b3JrIElQIGFkZHJlc3Nlcy4gVGhleTxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7IG1heSBiZSBob3N0ZWQgb24gZGV2aWNlcyBp
biBzdGVhbHRoIG1vZGUgb3Igd2l0aCBkeW5hbWljIElQIGFkZHJlc3NlcyBzbzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7IG1hcHBpbmcgYmV0d2VlbiB0aGUgcmVzb3VyY2VzIGFu
ZCBJUCBpcyBub3QgZWZmaWNpZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtYmFkcmEtdGxzLXBhc3NpdmUtY2xpZW50LTAwIHNheXM6PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPiZndDsgT25jZSB0aGUgaW5pdGlhbCBoYW5kc2hha2luZyBpcyBjb21w
bGV0ZSwgdGhlIHNlcnZlciBNQVkgYWN0aXZlbHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+Jmd0OyBvcGVuIGEgVENQIG9yIFVEUCBjb25uZWN0aW9uIHRvIHRoZSBjbGllbnQgdXNpbmcg
dGhlIHBvcnQgbnVtYmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgcmVjZWl2
ZWQgaW4gdGhlIENsaWVudEhlbGxvLiZuYnNwOyBPbmNlIHRoZSBUQ1Agb3IgVURQIGNvbm5lY3Rp
b24gaGFzIGJlZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0OyBlc3RhYmxpc2hl
ZCwgdGhlIGNsaWVudCB0YWtlcyBpbml0aWF0aXZlIGFuZCBzZW5kcyB0aGUgVExTPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgQ2xpZW50SGVsbG8gbWVzc2FnZSB0byBiZWdpbiB0
aGUgVExTIGFiYnJldmlhdGVkIGhhbmRzaGFrZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIGlmIGFuIGF0dGFja2Vy
IHdlcmUgdG8gaW50ZXJjZXB0IHRoaXMgVENQIGNvbm5lY3Rpb24gY29taW5nIGZyb208bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhlIGxlZ2l0aW1hdGUgc2VydmVyLCBjb3VsZG7igJl0
IGhlIGp1c3Qgc2VuZCBhIENsaWVudEhlbGxvLCBlc3RhYmxpc2g8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+aGlzIG93biBzZXNzaW9uLCBhbmQgdGh1cyBsZWFybiB3aGF0ZXZlciB0aGUg
bGVnaXRpbWF0ZSBzZXJ2ZXIgaGFkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmludGVu
ZGVkIHRvIHNheSB0byB0aGUgYXBwbGljYXRpdmUgcmVzb3VyY2Ugc2VydmVyIGFuZCBwb3NzaWJs
eSBldmVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmZvcmdlIGEgcmVzcG9uc2U/PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21z
by1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y
ZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8
L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPk1hcnNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm
IE9mIDwvYj5Nb2hhbWFkIEJhZHJhPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgRGVjZW1iZXIg
MTUsIDIwMTMgMTozNCBBTTxicj4NCjxiPlRvOjwvYj4gV2F0c29uIExhZGQ8YnI+DQo8Yj5DYzo8
L2I+IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gUGFzc2l2ZSBU
TFMgQ2xpZW50cyAtIFJldmVyc2UgQ29ubmVjdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9uIFN1biwgRGVjIDE1LCAyMDEzIGF0IDQ6
NDcgQU0sIFdhdHNvbiBMYWRkICZsdDs8YSBocmVmPSJtYWlsdG86d2F0c29uYmxhZGRAZ21haWwu
Y29tIiB0YXJnZXQ9Il9ibGFuayI+d2F0c29uYmxhZGRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBEZWMgMTQsIDIwMTMgYXQgNDo0
MSBQTSwgTW9oYW1hZCBCYWRyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iYWRyYUBnbWFpbC5jb20i
Pm1iYWRyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IERlYXIgQWxsLDxicj4N
CiZndDs8YnI+DQomZ3Q7IEkndmUgc3VibWl0dGVkIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQgdG8g
ZW5hYmxlIGEgVExTIGNvbm5lY3Rpb24gZnJvbSBhPGJyPg0KJmd0OyBzZXJ2ZXIgdG8gYSBjbGll
bnQgYWZ0ZXIgdGhlIGluaXRpYWwgaGFuZHNoYWtlIGlzIGNvbXBsZXRlLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB5b3UgaGF2ZSBhIHVzZSBjYXNlIGZv
ciB0aGlzPyBCZWNhdXNlIG9uY2UgdGhlIGhhbmRzaGFrZSBmaW5pc2hlczxicj4NCnlvdSBoYXZl
IGEgcGVyZmVjdGx5IGdvb2QgY29ubmVjdGlvbi48YnI+DQpJZiBhbiBhcHBsaWNhdGlvbiBwcm90
b2NvbCByZXF1aXJlcyB0aGlzLCBpdCBjYW4gZG8gaXQgYXQgdGhlIGFwcGxpY2F0aW9uIGxldmVs
Ljxicj4NClNpbmNlcmVseSw8YnI+DQpXYXRzb24gTGFkZDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j
a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7i
gIvigItJIGRvbid0IGhhdmUgYW4gZXhoYXVzdGl2ZSBsaXN0IG9mIHNjZW5hcmlvcyB3aGVyZSB0
aGlzIGV4dGVuc2lvbiBjb3VsZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5iZSB1c2VmdWw6PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj7igIstIFNvbWUgb2YgdGhlIGFwcGxpY2F0aXZlIHJlc291cmNlcyBtYXkgYmUg
aG9zdGVkIGJlaGluZCBhIHByb3h5IG9yIGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZpcmV3YWxsIHRoYXQgaW1wbGVtZW50cyBOQVQgZm9yIHRo
ZSBpbnRlcm5hbCBuZXR3b3JrIElQIGFkZHJlc3Nlcy4gVGhleTxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bWF5IGJlIGhvc3RlZCBvbiBkZXZpY2Vz
IGluIHN0ZWFsdGggbW9kZSBvciB3aXRoIGR5bmFtaWMgSVAgYWRkcmVzc2VzIHNvPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tYXBwaW5nIGJldHdl
ZW4gdGhlIHJlc291cmNlcyBhbmQgSVAgaXMgbm90IGVmZmljaWVudC48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4tIEl0IGlzIHN1aXRhYmxlIGZvciBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2xz
IHN1Y2ggYXMgTkVUQ09ORigqKS4gSXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+d2lsbCBiZSBlYXNpZXIgdG8gZXh0
ZW5kIFRMUyB0aGFuIHJldmlzaW5nIGV2ZXJ5IGFwcGxpY2F0aW9uIHRvIGVuYWJsZTwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij5yZXZlcnNlIGNvbm5lY3Rpb24gb3ZlciBUTFMgQW5kIGFzc2lnbiBhIG5ldyBwb3J0IG51
bWJlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij4tIEluIHRoZSBjYXNlIG9mIHJldmVyc2UgY29ubmVjdGlvbnMs
IGl0IHdvdWxkIGJlIG1vcmUgc2VjdXJlIHRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmNvbmZpZ3VyZSB5b3VyIHNl
cnZlciAoaXQgbWF5IGJlIGVhc2llciB0byBzZWN1cmUgb25lIG9wZW4gcG9ydCB0aGFuIHRvPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPmhhdmluZyBhbiBvcGVuIHBvcnQgb24gZWFjaCBzZXJ2ZXIgaW4gdGhlIG5ldHdv
cmspLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPigqKSBPdGhlciBiZW5lZml0cyByZWxhdGVkIHRvIGRl
dmljZSBtYW5hZ2VtZW50IG1heSBiZSBmb3VuZCBhdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRw
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtcmV2ZXJzZS1zc2gtMDIj
c2VjdGlvbi0zIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYt
cmV2ZXJzZS1zc2gtMDIjc2VjdGlvbi0zPC9hPi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CZXN0IHJlZ2FyZHMs
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPkJhZHJhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+
DQo=

--_000_9b71054038a54d40b1f686497b3eb162BY2PR03MB074namprd03pro_--

From mbadra@gmail.com  Tue Dec 17 06:10:13 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C5E1AE25D for ; Tue, 17 Dec 2013 06:10:13 -0800 (PST)
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 9rByRIEd3JzT for ; Tue, 17 Dec 2013 06:10:11 -0800 (PST)
Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 40BCD1AE234 for ; Tue, 17 Dec 2013 06:10:11 -0800 (PST)
Received: by mail-ve0-f181.google.com with SMTP id oy12so4394674veb.12 for ; Tue, 17 Dec 2013 06:10:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=00T32sKA2+kWslg59GvUJmn0Yk0Hm+6UAhuVTGODbwQ=; b=hfoxcjJMlOHgkqM+VDVh0M8VOh8JkVJP33+74xJEmiv3w5FOz50UO1FDdShHT+we2u DQuBuvFYI9jDt0JnrSVRSJbNgkYsvPNoPnuz9FK/7YTrFjex2JwKO6sDpQGcr7W6mGoe cwtlE1EHTUjnhF5HmtlWAQgT8crKcrwkWS/l6ma+dbJpAkxe8K31Wr2JCXxSArepRxAy cC7kqt3w8bbfx2B81nMgy+u+CCw5cuZ32C3hhtv2f1PpUK/cNXFbo4JGSUX/RSgW1rzx uKunK1Z5QQV9VtqD15t/742w9zQ9uyUAUIq0MOdtMsXKN076P3DIA2UDyuf3B8d9eocy Gzhw==
MIME-Version: 1.0
X-Received: by 10.221.19.196 with SMTP id ql4mr437480vcb.54.1387289410017; Tue, 17 Dec 2013 06:10:10 -0800 (PST)
Received: by 10.220.165.132 with HTTP; Tue, 17 Dec 2013 06:10:09 -0800 (PST)
In-Reply-To: <9b71054038a54d40b1f686497b3eb162@BY2PR03MB074.namprd03.prod.outlook.com>
References:    <9b71054038a54d40b1f686497b3eb162@BY2PR03MB074.namprd03.prod.outlook.com>
Date: Tue, 17 Dec 2013 18:10:09 +0400
Message-ID: 
From: Mohamad Badra 
To: Marsh Ray 
Content-Type: multipart/alternative; boundary=001a11339b207c20b704edbb7c92
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Passive TLS Clients - Reverse Connections
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 17 Dec 2013 14:10:13 -0000

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

On Tue, Dec 17, 2013 at 9:39 AM, Marsh Ray  wrote:

>  *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Mohamad Badra
> > Some of the applicative resources may be hosted behind a proxy or a
>
> > firewall that implements NAT for the internal network IP addresses. The=
y
>
> > may be hosted on devices in stealth mode or with dynamic IP addresses s=
o
>
> > mapping between the resources and IP is not efficient.
>
>
>
> http://tools.ietf.org/html/draft-badra-tls-passive-client-00 says:
>
> > Once the initial handshaking is complete, the server MAY actively
>
> > open a TCP or UDP connection to the client using the port number
>
> > received in the ClientHello.  Once the TCP or UDP connection has been
>
> > established, the client takes initiative and sends the TLS
>
> > ClientHello message to begin the TLS abbreviated handshake.
>
>
>
> So if an attacker were to intercept this TCP connection coming from
>
> the legitimate server, couldn=E2=80=99t he just send a ClientHello, estab=
lish
>
> his own session, and thus learn whatever the legitimate server had
>
> intended to say to the applicative resource server and possibly even
>
> forge a response?
>
=E2=80=8B=E2=80=8B

As indicated in the document, the client takes the initiative to begin an
"abbreviated" handshake, so he must include the session identifier
generated during the initial Handshake in the ClientHello. The server
shall reject that handshake in case the Finished message is not valid.

Best regards,
Badra

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


On Tue, Dec 17, 2013 =
at 9:39 AM, Marsh Ray =
<maray@microsof=
t.com> wrote:













From: TLS [mailto:tls-bounces@ietf.org]
On Behalf Of Mohamad Badra


> Some of the applicative resources=
 may be hosted behind a proxy or a



> firewall that implements NAT for the in=
ternal network IP addresses. They


> may be hosted on devices in stealth mod=
e or with dynamic IP addresses so


> mapping between the resources and IP is=
 not efficient.


=C2=A0


http://tools.ietf.org/=
html/draft-badra-tls-passive-client-00 says:



> Once the initial handshaking is complet=
e, the server MAY actively


> open a TCP or UDP connection to the cli=
ent using the port number


> received in the ClientHello.=C2=A0 Once=
 the TCP or UDP connection has been


> established, the client takes initiativ=
e and sends the TLS


> ClientHello message to begin the TLS ab=
breviated handshake.


=C2=A0


So if an attacker were to intercept this TCP=
 connection coming from


the legitimate server, couldn=E2=80=99t he j=
ust send a ClientHello, establish


his own session, and thus learn whatever the=
 legitimate server had


intended to say to the applicative resource =
server and possibly even


forge a response?
=E2=80=8B=E2=80=8B


As indicated in the document, the client takes the initiative =
to begin an


&q=
uot;abbreviated" handshake, so he must include the session identifier<=
/font>
generated during the initial Handshake in the ClientHello. The se=
rver


sh=
all reject that handshake in case the Finished message is not valid.=



Best regards,
Badra


--001a11339b207c20b704edbb7c92--

From watsonbladd@gmail.com  Tue Dec 17 16:28:26 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EC21ADF4C for ; Tue, 17 Dec 2013 16:28:26 -0800 (PST)
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 EmxobpYWWbIm for ; Tue, 17 Dec 2013 16:28:25 -0800 (PST)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C0B141ADF30 for ; Tue, 17 Dec 2013 16:28:24 -0800 (PST)
Received: by mail-wi0-f171.google.com with SMTP id bz8so4541255wib.16 for ; Tue, 17 Dec 2013 16:28:23 -0800 (PST)
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=YEsURlM2GMxNua9yBhYuzxXfgk05ckQs0Rkwc8cwaf4=; b=S6/plzipQEQhzieY6+R876+h/AFdSJ1vaQnid0C7enxmjdKROt1roYMHW0p7q+o2Wy N7iCMROAxVZh4sfKZG36AKxxcM/go9437X3mYOvRlLetKMnCxOJ+S5jtPGS4RzwRvfci KTOyeUsxr86LTcCjy/Q20aQj6OD2bVV7jhxZvf7p77jZ+N23l6hm6wu5waWJ57ya7UBn aF9ixjvwF/UoChMzJNTIghHzNUcR3V/e/lQWZ84SfEWMVe3fe82z5HCTJDKM2lO3PGvt 4vu+RnmXEU3HbnTD127WC/GqG2NiHxRssHQZBb388Jup561i4G5k+sq0IBE5YppwxjOR Bqag==
MIME-Version: 1.0
X-Received: by 10.194.61.211 with SMTP id s19mr14772279wjr.73.1387326503035; Tue, 17 Dec 2013 16:28:23 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Tue, 17 Dec 2013 16:28:23 -0800 (PST)
Date: Tue, 17 Dec 2013 16:28:23 -0800
Message-ID: 
From: Watson Ladd 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Subject: [TLS] The threat (for 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: Wed, 18 Dec 2013 00:28:26 -0000

http://koen.io/2013/12/flying-pig-gchq-tls-ssl-knowledge-base/

It appears that the information leaked in the TLS handshake is of
significant interest to people. Can anyone get the original
presentation slides/documents so we can see exactly what is going on?

Sincerely,
Watson Ladd

From fabrice.gautier@gmail.com  Fri Dec 20 10:25:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84671AE0F2 for ; Fri, 20 Dec 2013 10:25:41 -0800 (PST)
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 O5rX8mcsag0o for ; Fri, 20 Dec 2013 10:25:40 -0800 (PST)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 67C8E1AE0F1 for ; Fri, 20 Dec 2013 10:25:40 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id a1so2831353wgh.29 for ; Fri, 20 Dec 2013 10:25:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=yoGbRWpbsX+vDWUlWP+x+8dvYtJzxbQAPiCeDplZyoU=; b=y52Gr80bEsAW4zXihuX8UpSGaxjLGs/kEgg4x3PhFyUOBzv2kJF8uSBqGE0fw9Cr3L W2VJz9aa1O5z5QmxHLLis8FOfu3LnxT3IIK/lib6AP9I/6N8yCNEOT69In6jCTQCCmXu a7HBJ55UHbdLd+6RuEQ45t352ldRc35TvBnYzsdYvKoyy+DFSOgwdbjrd9DMB9Sx6Qah ADtwUbbxX2qA9MK7AR7tBCtlX8KWdZz4zuflLhCrVq7vyeLBq0d83yW9rsiokesTIGZ/ Cps7pfnbEoqV4fVIyXl/18O4RTnAlleUsHk39jb4nOhnoUxplWO5nCoJm4oCzbee9wMT jAjw==
X-Received: by 10.180.228.132 with SMTP id si4mr9061510wic.2.1387563937426; Fri, 20 Dec 2013 10:25:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.84.202 with HTTP; Fri, 20 Dec 2013 10:25:16 -0800 (PST)
From: Fabrice Gautier 
Date: Fri, 20 Dec 2013 10:25:16 -0800
Message-ID: 
To: "" 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [TLS] DTLS cookie and session resumption.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 20 Dec 2013 18:25:42 -0000

Hi,

Is it safe for a DTLS server not to perform a cookie verification and
send a ClientHelloVerifyRequest message if the ClientHello sessionID
point to a session that can be resumed successfully ?

I'm assuming it's not in general. For example, an attacker could first
perform a full connection, then DDOS the server with resumption
attempts.


-- Fabrice

From mbadra@gmail.com  Mon Dec 23 03:02:09 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5021AC4C5 for ; Mon, 23 Dec 2013 03:02:09 -0800 (PST)
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_20=-0.001, 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 ea8JNFC_fRSp for ; Mon, 23 Dec 2013 03:02:08 -0800 (PST)
Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 10C511AC404 for ; Mon, 23 Dec 2013 03:02:08 -0800 (PST)
Received: by mail-pd0-f181.google.com with SMTP id p10so4979526pdj.26 for ; Mon, 23 Dec 2013 03:02:05 -0800 (PST)
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=+CUa4/+OQlMcZuUzJ7F7lVX60hcuoOD6A7caCMsCDFA=; b=oL7IJfVM/FuyC7X3SpXZ63Mu0H3mCz6MQ9tOSg4QpV7QzsiSji8uHTBySL8hs2pnSf V3sYEIBP298iGO2wzyrP6n1LfoXNy+/nOW5AJentQdS5gDXFa00PP+5/CpZ5QWN0FOmu iZqxWV2OSmXqxmqpVmb6uWuMJINQr165Xh9YCyj8zHutlxmcVWdEJO2FqqzxGkkc3S+l U7cey/0jeCgTxV2RkrNoldxvQI2mlo4HA/D3K0mD7jllI6b7AOWFJbwmvThb4PH58bZ2 graY/z+Ht+P+x1y4OgW1qcX1ISfo4Y/4Hb+C7AnacYRRQj6kmLbVFOgomGvOe/ZbuHgH jFhg==
MIME-Version: 1.0
X-Received: by 10.68.230.228 with SMTP id tb4mr25124218pbc.108.1387796524955;  Mon, 23 Dec 2013 03:02:04 -0800 (PST)
Received: by 10.66.145.72 with HTTP; Mon, 23 Dec 2013 03:02:04 -0800 (PST)
Date: Mon, 23 Dec 2013 15:02:04 +0400
Message-ID: 
From: Mohamad Badra 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b33c7a4e3ff9404ee318e91
Subject: [TLS] Breaking 4096-bit RSA with an Acoustic Cryptanalysis attack
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 23 Dec 2013 11:02:10 -0000

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

http://www.tau.ac.il/~tromer/papers/acoustic-20131218.pdf

--047d7b33c7a4e3ff9404ee318e91
Content-Type: text/html; charset=UTF-8



--047d7b33c7a4e3ff9404ee318e91--

From akr@akr.io  Mon Dec 23 03:22:24 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474ED1ADF6A for ; Mon, 23 Dec 2013 03:22:24 -0800 (PST)
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 GN5N6-i6GFm1 for ; Mon, 23 Dec 2013 03:22:19 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6C91ADF64 for ; Mon, 23 Dec 2013 03:22:19 -0800 (PST)
Received: from [10.99.96.108] (94.197.121.92.threembb.co.uk [94.197.121.92]) by entima.net (Postfix) with ESMTPSA id CB44860083 for ; Mon, 23 Dec 2013 11:22:14 +0000 (GMT)
User-Agent: K-9 Mail for Android
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: Alyssa Rowan 
Date: Mon, 23 Dec 2013 11:22:07 +0000
To: "tls@ietf.org" 
Message-ID: <69aae78b-0e97-457f-9b4f-cacd0c31cf20@email.android.com>
Subject: Re: [TLS] Breaking 4096-bit RSA with an Acoustic Cryptanalysis attack
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 23 Dec 2013 11:22:24 -0000

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

Mohamad Badra  wrote:
>http://www.tau.ac.il/~tromer/papers/acoustic-20131218.pdf

Interesting work, following up their paper from 2004.

Wonder how this impacts common TLS libraries? We should evaluate. Whatever countermeasures are good for GnuPG are probably also applicable to OpenSSL, and the like... would the attack perhaps be more practical, given TLS is online and GnuPG usually not? Or less, given the way RSA (and DHE?) is used in TLS? Thoughts?

I note some new primitives like Curve25519, its faster (but equivalent) cousin Ed25519 and the larger Curve3617 use constant-time ladders and no data-dependent branches, and would address this issue going forward if adopted.

- --
/akr
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.9

iQI3BAEBCgAhBQJSuBzfGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t6CocP/RywFu8dTsnAAfr+hUWzEWapO7GIbILZONA5LjAbNUOiynnY296O
pYqoG0UKDM8yjAENJzpql07Mrn5iKPKRMVd/OfbxQZgwrOfcvFo5Vb7WKVi/6uJF
BX3u8W61wdqqgEL3ZXU12P5rROIek0syuHxICLzur9j4Rhxn6gc6W7Kazd92jWhB
lYSGSNNFbnkKS9X4NsdIBfBKgQ7gzQXZBtCHEmfpA89yqvLukf0b9seSvD+qUlFb
y44/M0yzL0PJ94SNURLrwq3BTATRZdD2RL9Lb0TDrMaXM8a/WIt98DdC+VLmlFig
Retd5WrcjXKzyqK6NHx/niQDe2ojMVlplp87NSzSq5ElY3c0hhmQMyxUT+yX/mqp
jB/JFW1ytR4LCGfBpKsoFYosVfILsXUJsnB0RVxN9Tv0mW1Ih+jbXR1rdlIJZyiR
jdzjXzVkpvbc3FiQft5e7qc+DaOfk00ozJQZgBEztspwd8p/2x8iEmRFZ1L7vsFh
9R3ebb8f7+A0ZbmaIgwhHADMDcKzBxn/Al0h/LuJJJW8KZQtB9QmjKLpEWU8Ui8X
SIgDYipEM7cKyHMkHoedfYhov1TIk/VIuO/3NTCMCxyYxSkoj4kISTveNeyD+Arq
bIJyVU4XPaXddsiTv1vwH/Z2bJdNu7AC+j45wcJKMeJ4Va5Xl2DogAEt
=qbN3
-----END PGP SIGNATURE-----


From nmav@redhat.com  Mon Dec 23 03:49:22 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847C11ADFB9 for ; Mon, 23 Dec 2013 03:49:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.44
X-Spam-Level: 
X-Spam-Status: No, score=-7.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 DeH83TSqZLpv for ; Mon, 23 Dec 2013 03:49:21 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id E73C31ADFB6 for ; Mon, 23 Dec 2013 03:49:20 -0800 (PST)
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 rBNBnF3Q029742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Dec 2013 06:49:15 -0500
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 rBNBnDe2005104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Dec 2013 06:49:14 -0500
Message-ID: <1387799352.13356.7.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Alyssa Rowan 
Date: Mon, 23 Dec 2013 12:49:12 +0100
In-Reply-To: <69aae78b-0e97-457f-9b4f-cacd0c31cf20@email.android.com>
References:  <69aae78b-0e97-457f-9b4f-cacd0c31cf20@email.android.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
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Breaking 4096-bit RSA with an Acoustic Cryptanalysis attack
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 23 Dec 2013 11:49:22 -0000

On Mon, 2013-12-23 at 11:22 +0000, Alyssa Rowan wrote:
> Mohamad Badra  wrote:
> >http://www.tau.ac.il/~tromer/papers/acoustic-20131218.pdf
> 
> Interesting work, following up their paper from 2004.
> 
> Wonder how this impacts common TLS libraries? We should evaluate.
> Whatever countermeasures are good for GnuPG are probably also
> applicable to OpenSSL, and the like... would the attack perhaps be more
> practical, given TLS is online and GnuPG usually not? Or less, given
> the way RSA (and DHE?) is used in TLS? Thoughts?

As far as I understand the attack, it applies to RSA implementations
that don't involve blinding. That's why they target gnupg 1.4 (and
not the latest gnupg 2.x versions). I believe that all the TLS
implementations have RSA blinding enabled. Nevertheless the mitigation
section of the paper has some good advice (e.g., on making sure that
the encrypted value is within the expected range).

regards,
Nikos



From nmav@redhat.com  Mon Dec 23 04:46:44 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0D21ADFCF for ; Mon, 23 Dec 2013 04:46:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.44
X-Spam-Level: 
X-Spam-Status: No, score=-7.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 Q6RLdmfVzCgO for ; Mon, 23 Dec 2013 04:46:43 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8777E1ADFB8 for ; Mon, 23 Dec 2013 04:46:43 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBNCkcxm025804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Dec 2013 07:46:38 -0500
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBNCkZNr010603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Dec 2013 07:46:36 -0500
Message-ID: <1387802795.13356.33.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Fabrice Gautier 
Date: Mon, 23 Dec 2013 13:46:35 +0100
In-Reply-To: 
References: 
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.22
Cc: "" 
Subject: Re: [TLS] DTLS cookie and session resumption.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 23 Dec 2013 12:46:45 -0000

On Fri, 2013-12-20 at 10:25 -0800, Fabrice Gautier wrote:

> Is it safe for a DTLS server not to perform a cookie verification and
> send a ClientHelloVerifyRequest message if the ClientHello sessionID
> point to a session that can be resumed successfully ?
> 
> I'm assuming it's not in general. For example, an attacker could first
> perform a full connection, then DDOS the server with resumption
> attempts.

Or the attacker could sniff one session ID and then flood the server
using it.

regards,
Nikos



From martin.thomson@gmail.com  Mon Dec 23 09:01:48 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DADE1AE1CD for ; Mon, 23 Dec 2013 09:01:48 -0800 (PST)
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 Ana3XBgMvyOk for ; Mon, 23 Dec 2013 09:01:47 -0800 (PST)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 458321AE1CA for ; Mon, 23 Dec 2013 09:01:47 -0800 (PST)
Received: by mail-we0-f170.google.com with SMTP id w61so5172613wes.29 for ; Mon, 23 Dec 2013 09:01:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N/YpBthFDoAToTdFsu+y1N+BOB4CbeNyCvWNQhrokkc=; b=SVW/vtNW7y19LbFAoO0rmMjcNVxg0q5+A95meVQ6f7BIhx640lKM+9FsZxF+n+tKmu kMaes2SlWwzE1wBJipETPWXB3Q2MIDNivRQiYwMDdXL2wshSLFjwZNwxXoPPktTQwjBu Maf/l753OsmKF6alIvI2F95j/OZBd+r9tTVkgZstXCmIrdXYreFSpIbyOoMXh9iA3bLA ykOn44nQviEV3BXpIYaNmlDOhL+L6YUOGFIypVD4ckic0SqtPA3EU225DhRWMr7cnKjc zenaAP8dqWPvIR1VTkRtC1GSPiW2Piat9bI02WQ/YzkOM8AWKpiLKlRoFOKxGVFrkbIl ro6g==
MIME-Version: 1.0
X-Received: by 10.194.202.230 with SMTP id kl6mr19792022wjc.9.1387818103512; Mon, 23 Dec 2013 09:01:43 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Mon, 23 Dec 2013 09:01:43 -0800 (PST)
In-Reply-To: 
References: 
Date: Mon, 23 Dec 2013 09:01:43 -0800
Message-ID: 
From: Martin Thomson 
To: Fabrice Gautier 
Content-Type: text/plain; charset=UTF-8
Cc: "" 
Subject: Re: [TLS] DTLS cookie and session resumption.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 23 Dec 2013 17:01:48 -0000

On 20 December 2013 10:25, Fabrice Gautier  wrote:
> I'm assuming it's not in general. For example, an attacker could first
> perform a full connection, then DDOS the server with resumption
> attempts.

That's true in general, as Nikos points out.  That said, if you are
using something like ICE [RFC5245], this can be avoided by limiting
the number of DTLS connections to one for each remote ICE username
fragment.

From akr@akr.io  Thu Dec 26 10:03:02 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187701AE279 for ; Thu, 26 Dec 2013 10:03:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level: 
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ExwTONVRWwWB for ; Thu, 26 Dec 2013 10:03:00 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 16ABD1AE22B for ; Thu, 26 Dec 2013 10:03:00 -0800 (PST)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id 5AE4B60A1C for ; Thu, 26 Dec 2013 18:02:54 +0000 (GMT)
Message-ID: <52BC6F5B.20500@akr.io>
Date: Thu, 26 Dec 2013 18:03:07 +0000
From: Alyssa Rowan 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tls@ietf.org
References:  <69aae78b-0e97-457f-9b4f-cacd0c31cf20@email.android.com> <52BC66BD.80300@polarssl.org>
In-Reply-To: <52BC66BD.80300@polarssl.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] Breaking 4096-bit RSA with an Acoustic Cryptanalysis attack
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 26 Dec 2013 18:03:02 -0000

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

On 26/12/2013 17:26, Manuel Pégourié-Gonnard wrote:

> I don't agree with all of this statement: Curve25519 (and similar
> curves) come with a convenient ladder indeed, but "no
> data-dependent branches" is a property of the implementation, not
> of the curve/primitive itself.

A fair point! A better wording on my part would have been that it's
easier and faster to implement these new curves in a manner that
avoids side-channel attacks than it is older, comparable primitives.

As you correctly point out, great care is still required. There exist
possible implementations of both Montgomery and Edwards ladders that
exhibit cache and timing attacks: perhaps we should specifically point
out that these are to be avoided, in any I-D which specifies the use
of these curves.

They seem so useful that I anticipate at this stage that TLS1.3 may be
greatly benefitted by using them for EdDSA, key exchange/forward
security, and possibly ClientHello encryption - I personally can't
think of a more suitable contender.

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

iQIcBAEBCgAGBQJSvG9bAAoJEOyEjtkWi2t6EmcQAK6hcxap1yNEP0yTqcaSNAgX
ZGfjpg0ocxzxIca1VC+rF9rd9ocDurhhORkozq4n82c+j7Y28N0YoId29AWi1Chf
H9FmwlhPCCRELyUuWsT3Mjjcd6BSsQt6f8FKR/k7BbTaoNndk93LKZy9UllNyyhp
8b8nvC4zFrvJ9IRXovy2lkM/P8L5WeMKq1z9Wx9IurzbleokKC8ejkXfPOvhhJ6c
xkNziWmqDUNs+oxhpeEbMVR3K6D49F8K3Q+JHYZFCC3ZxdZhW7qF2apBH1aLOxf7
KCCWFzuoKzm6Zs8Zi58JOq3hhzu7xQ6Lr0zktYOKAIbe2SGPj/cNtIl9LsMtnBEl
kb51r75BNc5B7aiNhAlME7CFZ2cTVDUfL/YhBp5SOamRf5fAFalXI5VPX5kEk9NT
HWHDKZDFjpRtr3ozY5BZPAPmu5waub49yfI5N/jcS1xtK/YrFQZg9ApZvfK2X9Fb
s9y8bxN9x7qSgfmV2tsv3f7yJuF3kKXGHgkrJtIAELS5zLAF7yUcEKL4Y7Hb8JWK
SJeBJERFgCIg/uenj5xT1QVAHOdDNyqBhKBzECa9tTDQA+SSGGvmW0scvhfXNyq/
/iDeZE6Wo+vbSv/JH3Oy4FWXLMCwPrISMyz+PIvluOMy37/G2ByaHVFUzh/ttk03
wLMMx58n29euqooZMxjE
=+KyL
-----END PGP SIGNATURE-----

From sneves@dei.uc.pt  Thu Dec 26 10:53:19 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E901AE009 for ; Thu, 26 Dec 2013 10:53:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.87
X-Spam-Level: **
X-Spam-Status: No, score=2.87 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, 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 2HnVPlxJGhXW for ; Thu, 26 Dec 2013 10:53:16 -0800 (PST)
Received: from smtp.dei.uc.pt (smtp.dei.uc.pt [193.137.203.253]) by ietfa.amsl.com (Postfix) with ESMTP id 758841AE001 for ; Thu, 26 Dec 2013 10:53:16 -0800 (PST)
Received: from [192.168.90.50] (bl6-83-86.dsl.telepac.pt [82.155.83.86]) (authenticated bits=0) by smtp.dei.uc.pt (8.14.4/8.14.4) with ESMTP id rBQIqa6L022273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Dec 2013 18:52:42 GMT
Message-ID: <52BC7AFA.7080206@dei.uc.pt>
Date: Thu, 26 Dec 2013 18:52:42 +0000
From: Samuel Neves 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tls@ietf.org
References:  <69aae78b-0e97-457f-9b4f-cacd0c31cf20@email.android.com> <52BC66BD.80300@polarssl.org> <52BC6F5B.20500@akr.io>
In-Reply-To: <52BC6F5B.20500@akr.io>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative; boundary="------------060609080806050403000309"
X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information
X-FCTUC-DEI-SIC-MailScanner-ID: rBQIqa6L022273
X-FCTUC-DEI-SIC-MailScanner: Found to be clean
X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-56.664, required 3.252, autolearn=not spam, ALL_TRUSTED -10.00, BAYES_00 -0.25, HTML_MESSAGE 0.10, L_SMTP_AUTH -50.00, RAZOR2_CF_RANGE_51_100 0.50, RAZOR2_CF_RANGE_E8_51_100 1.89, RAZOR2_CHECK 1.10)
X-FCTUC-DEI-SIC-MailScanner-From: sneves@dei.uc.pt
Subject: Re: [TLS] Breaking 4096-bit RSA with an Acoustic Cryptanalysis attack
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 26 Dec 2013 18:53:19 -0000

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

On 26-12-2013 18:03, Alyssa Rowan wrote:
> A fair point! A better wording on my part would have been that it's
> easier and faster to implement these new curves in a manner that
> avoids side-channel attacks than it is older, comparable primitives.

Montgomery (and most other) ladders are agnostic of the underlying
group, and can be used in RSA, DSA, etc (cf. [1]).

The reason they are not extremely popular outside of Montgomery curves
with x-only coordinates is that they are not very fast: 2 log(e) group
operations versus log(e) + log(e)/k + 2^k for k-ary approaches.

[1] http://www.joye.site88.net/papers/JY03mont.pdf


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


  
    
  
  
    On 26-12-2013 18:03, Alyssa Rowan wrote:

    > A fair point! A better wording
      on my part would have been that it's

      > easier and faster to implement these new curves in a manner
      that

      > avoids side-channel attacks than it is older, comparable
      primitives.

    

    Montgomery (and most other) ladders are agnostic of the underlying
    group, and can be used in RSA, DSA, etc (cf. [1]).

    

    The reason they are not extremely popular outside of Montgomery
    curves with x-only coordinates is that they are not very fast: 2
    log(e) group operations versus log(e) + log(e)/k + 2^k for k-ary
    approaches.

    

    [1] http://www.joye.site88.net/papers/JY03mont.pdf

    

  


--------------060609080806050403000309--

From mpg@polarssl.org  Thu Dec 26 09:26:31 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891D91AE23B for ; Thu, 26 Dec 2013 09:26:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.094
X-Spam-Level: ***
X-Spam-Status: No, score=3.094 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 E12LuY3b0Hus for ; Thu, 26 Dec 2013 09:26:30 -0800 (PST)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 35DEC1AE23A for ; Thu, 26 Dec 2013 09:26:29 -0800 (PST)
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=YIjBEBWz1h2Ry7x0ZBLg8WOQSj3/NevQaFxMepJFgXI=;  b=Z8mS/vf622V5b9uLsfcDxWXAvpKyUPNviGhURpnc6Un2mt30fFRNbPGPG54Zm31WYQJSH1y9RVq7kPR3L3Ctiirxs5QzeIBCIP6youNFuj4Ot1a5zeMCCLDRIIYjqGXhafKbd7Ko591l0rePwN2co1xziFi+nJ9imJg1OFNW/HU=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VwEaP-0006HR-1o; Thu, 26 Dec 2013 18:19:05 +0100
Message-ID: <52BC66BD.80300@polarssl.org>
Date: Thu, 26 Dec 2013 18:26:21 +0100
From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1
MIME-Version: 1.0
To: Alyssa Rowan , "tls@ietf.org" 
References:  <69aae78b-0e97-457f-9b4f-cacd0c31cf20@email.android.com>
In-Reply-To: <69aae78b-0e97-457f-9b4f-cacd0c31cf20@email.android.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)
X-Mailman-Approved-At: Sat, 28 Dec 2013 08:27:35 -0800
Subject: Re: [TLS] Breaking 4096-bit RSA with an Acoustic Cryptanalysis attack
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 26 Dec 2013 17:57:33 -0000

On 23/12/2013 12:22, Alyssa Rowan wrote:
> I note some new primitives like Curve25519, its faster (but equivalent)
> cousin Ed25519 and the larger Curve3617 use constant-time ladders and no
> data-dependent branches, and would address this issue going forward if
> adopted.
> 
I don't agree with all of this statement: Curve25519 (and similar curves) come
with a convenient ladder indeed, but "no data-dependent branches" is a property
of the implementation, not of the curve/primitive itself.

More specifically, the core of the the Montgomery ladder is:

  * for i from 0 to m do
     * if d[i] = 0 then
        * R1, R0 := R0 + R1, 2R0
     * else
        * R0, R1 := R0 + R1, 2R1

which has a branch depending directly on the bits d[i] of the secret exponent d.
It can easily be rewritten as

  * for i from 0 to m do
     * R[ 1-d[i] ], R[ d[i] ] = R0 + R1, 2R[ d[i] ]

which has no secret-data-dependent branches, but still has secret-data-dependent
memory access patterns. Additional care in the implementation (namely,
constant-time conditional swap) is required to avoid this potential source of
information leakage.

So, while it is true that Curve25519 & Co are easier to implement safely (in
PolarSSL, the code for Curve25519 is 4 times shorter and simpler that the code
for short Weierstrass curves, with comparable safety), and perform better than
short Weierstrass curves (for comparable implementations), some security
properties such as (1) "no secret-data-dependant branches" and (2) "no
secret-data-dependant memory access patterns" (and one might want to add (3)
"constant-time field arithmetic or coordinates randomisation") still do no come
for free with these curves and depend on the implementation.

Manuel.

From ekr@rtfm.com  Sun Dec 29 15:15:37 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B461AE32A for ; Sun, 29 Dec 2013 15:15:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.722
X-Spam-Level: 
X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ZLVMbCEVA1DF for ; Sun, 29 Dec 2013 15:15:35 -0800 (PST)
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9121AE2C0 for ; Sun, 29 Dec 2013 15:15:34 -0800 (PST)
Received: by mail-we0-f170.google.com with SMTP id w61so9776562wes.1 for ; Sun, 29 Dec 2013 15:15:28 -0800 (PST)
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=45XfDAgnItRpKiVGe6Eykkltsd/Dd8w1oRC/YQgM9us=; b=TEyJYo+0e97YQfUGE4SvRz16N1v/Xz+cKMky8E2+2ss76nQpdac4PEPt5yd3ww8dh+ Qvj4QJeR3sqNLwlsR+/h5uMcU69D9l99IHHBMbQTeQe3VPa2imDQiIt/cuZ+g4lL/rJF S3cma9iXQ5DLd2FfScuJA3AGuzIiXdTRUgUWnCdpv6Wii1y73mHOLWoREvM8yaAZeugU 4ggfIpHV03+IwA5dHXRjpIXwxafnB5NMwUH/fOHu4iYLmHRyD53tOviBxb6xqc5rQvBj y2bDT1QOFOLkVAiY4oSM8ndIEAJUncYzDeRFcjvvfVvBiIYYP4vY3JGyjzSItk68WCSw daQQ==
X-Gm-Message-State: ALoCoQmrzttRUYw8+zoy2u4kCY2aTVln8/vbt7mCnjAq8BfARgnziRVoLVml9wdqdqpu+GOJfJop
X-Received: by 10.180.84.166 with SMTP id a6mr41436551wiz.49.1388358928342; Sun, 29 Dec 2013 15:15:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Sun, 29 Dec 2013 15:14:47 -0800 (PST)
X-Originating-IP: [74.95.2.168]
From: Eric Rescorla 
Date: Sun, 29 Dec 2013 15:14:47 -0800
Message-ID: 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [TLS] Way forward on fixing CBC Mode
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 29 Dec 2013 23:15:37 -0000

Based on mailing list discussions and a number of 1:1 discussions,
including consultation with our AD, here is where the chairs think we
are with fixing CBC mode:

* While a number of people in the meeting were in favor of new cipher
suites, much of the list discussion favored an orthogonal signal that
modified all the cipher suites at once. Overall, the dominant
sentiment seems to be that people like and/or can live with an
orthogonal signal that modifies the record protection construction for
CBC mode only (i.e., that leaves AEAD and stream cipher modes
untouched).

* We do not have consensus on this exact construction. There seem to
be two major proposals:

 - Encrypt-then-MAC [draft-gutmann-tls-encrypt-then-mac-05]
 - Pad-MAC-Encrypt [draft-mavrogiannopoulos-new-tls-padding-00]

Based on mailing list discussion, we believe that there is likely to
be consensus for Encrypt-then-MAC, but we want to confirm this.


* What signal to use. Again, there are two proposals:

 - A TLS extension [draft-gutmann-tls-encrypt-then-mac-05,
                    draft-mavrogiannopoulos-new-tls-padding-00]
 - An SCSV [proposed by Martin Rex; no draft yet.]


* A number of WG participants expressed a desire to deprecate
CBC mode entirely. We will need to discuss this for TLS 1.3.


Any proposal here will need to have some story about how to prevent
downgrade attacks. This comes for free with the SCSV but needs
something separate for an extension.


We will be starting two separate threads to discuss these issues and
hope to quickly converge on consensus on these issues (please do not
follow up to this message with discussion of those issues). Assuming
that happens, we'll either propose adoption of an existing draft
(perhaps with appropriate modifications) or solicit a new draft from
proponents of whatever approach does have consensus. Our target is to
have a WG draft by end of January and have a WGLC by London.

-Ekr
[For the chairs]

From ekr@rtfm.com  Sun Dec 29 15:16:36 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2001AE333 for ; Sun, 29 Dec 2013 15:16:36 -0800 (PST)
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 ehhakxGOWgZM for ; Sun, 29 Dec 2013 15:16:34 -0800 (PST)
Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE5C1AE334 for ; Sun, 29 Dec 2013 15:16:34 -0800 (PST)
Received: by mail-we0-f182.google.com with SMTP id q59so9816349wes.27 for ; Sun, 29 Dec 2013 15:16:28 -0800 (PST)
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=5e9SC8pPxaeHoPuEeIeARmrY0KW6+XllnKmoeQTGnWo=; b=YcojBzfJ0Bem1Btj2YlC0DhmXcw9N8mSpeoO8OdOTZEAmPnVoPVJzvacucMcaVQIJV fvBvptPCuqmdpK5WPflhWisv5LBS9x8XJXnl4qIBmYE6EO2bmYGBw/xiF5TKt/r9mWyW TVT5sBQqTVR0jOvyyoDdHs5D8Dql8T5x1yoLxPfdlbbC1cLsiPz3xPXqMBh1URSE1Ba6 F4C+DbFI+zppb5eJIZk6Y9GxnHjKanYonwK7P8g5LJdkB1n7we7DOB2RyW15GrwEa0db nFqppTfZAYAoM2TZvWHmoKUax9RIqS0oNdfSG4m4rTcreAo3u6/TTApachAZClZOLDAR b8vg==
X-Gm-Message-State: ALoCoQmDsKs99B01VKvc2X/LDRnZtrJ+ApNJfgFL62e9Aj04sk6CSRrOCAHD5juxbwqhHKHdMsJc
X-Received: by 10.180.12.115 with SMTP id x19mr10215367wib.49.1388358988145; Sun, 29 Dec 2013 15:16:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Sun, 29 Dec 2013 15:15:47 -0800 (PST)
X-Originating-IP: [74.95.2.168]
From: Eric Rescorla 
Date: Sun, 29 Dec 2013 15:15:47 -0800
Message-ID: 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [TLS] Fixing CBC Mode I: GenericBlockCipher construction
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 29 Dec 2013 23:16:36 -0000

We have seen two major proposals for fixing the GenericBlockCipher
construction:

- Encrypt-then-MAC
- Pad-MAC-Encrypt

The sense of the chairs is that the Encrypt-then-MAC construction
has greater support (see, for instance, the thread started by
http://www.ietf.org/mail-archive/web/tls/current/msg10584.html)
but we would like to confirm that impression.

If you have a comment to make about this, please do so by
January 10, 2014.


-Ekr
[For the Chairs]

From ekr@rtfm.com  Sun Dec 29 15:17:16 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2751AE330 for ; Sun, 29 Dec 2013 15:17:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.079
X-Spam-Level: 
X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 sGebVCr32H7K for ; Sun, 29 Dec 2013 15:17:15 -0800 (PST)
Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id C8AD31AE32A for ; Sun, 29 Dec 2013 15:17:14 -0800 (PST)
Received: by mail-we0-f179.google.com with SMTP id q59so9472827wes.24 for ; Sun, 29 Dec 2013 15:17:08 -0800 (PST)
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=X9Ny4uf/qFH2cyzFGD5XDcAqKW28TytHHEmBq/JhqLc=; b=Ig/cvr8stFejnBC/nhitW2Qo3E9AGjnhJa/xs/6FmqzdUtGMbU7vHryYIgd2teNd6l vkcZlTrkIFixAEauT+igqQsrVFFnABBo2rn8LLgIlXPVyYrM1MwopzGH4wK0u+v7lPCn VhWa1BcPYcgVAJv5dUU33eOqjsHCa4og3cxCUD05vSUEM8M8zRBReY0oVfVWppFn+NZ7 +bnLsqXL106cZrcK+LE9kTE+DUjTKkDLsX4fXhVuF8Jso+fSJkv77KU0elGOG5lcMPKM lpxNQho63Wu5k5okSFBjikycQTiOFB3r40CUW/JT+XWMEXnHtoR0fUj5yfeWOVsuYFIc S4nA==
X-Gm-Message-State: ALoCoQkS72mIKlX+CBQ0QIbyhvABmlzt78Hqa2w2dV+UUFGzlt8Ahf19YdCRA0XSc9QasRmveefK
X-Received: by 10.194.222.38 with SMTP id qj6mr17655073wjc.66.1388359028784; Sun, 29 Dec 2013 15:17:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Sun, 29 Dec 2013 15:16:28 -0800 (PST)
X-Originating-IP: [74.95.2.168]
From: Eric Rescorla 
Date: Sun, 29 Dec 2013 15:16:28 -0800
Message-ID: 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [TLS] Fixing CBC Mode II: Indicating new GenericBlockCipher construction
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 29 Dec 2013 23:17:16 -0000

WG Members,

We have seen two major proposals for indicating the use of a fixed
GenericBlockCipher construction:

- Use a TLS Extension
- Use an SCSV


Either of these will work within the context of TLS negotiation.

However, because some browsers do version fallback to compensate
for extension intolerance, the extension approach is potentially
subject to active attackers simulating extension-intolerant
servers. It therefore must be paired with something to prevent
fallback, such as:

- Refusal to fall back below TLS 1.0 (which requires extension
  tolerance)

- An ancillary anti-fallback mechanism, such as:
  draft-bmoeller-tls-downgrade-scsv-01 (the requirement
  here would likely be something like the server MUST support
  this draft if they support the new CBC mode).


The alternate SCSV approach does not have this problem, but as
a number of people have suggested, it is inelegant to keep adding
a lot of additional SCSVs.


If you have something to say about this issue, please do so
between now and January 10. We would particularly like to hear
from browser vendors about which approaches they believe are
viable given the existing server and intermediary infrastructure.

-Ekr
[For the chairs]

From akr@akr.io  Sun Dec 29 16:03:28 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B091AE330 for ; Sun, 29 Dec 2013 16:03:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level: 
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 HoMYBypvuAur for ; Sun, 29 Dec 2013 16:03:26 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id ED8C71AE0A9 for ; Sun, 29 Dec 2013 16:03:25 -0800 (PST)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id AA3B56038A for ; Mon, 30 Dec 2013 00:03:18 +0000 (GMT)
Message-ID: <52C0B85A.2080304@akr.io>
Date: Mon, 30 Dec 2013 00:03:38 +0000
From: Alyssa Rowan 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Fixing CBC Mode I: GenericBlockCipher construction
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 00:03:28 -0000

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

On 29/12/2013 23:15, Eric Rescorla wrote:

> - Encrypt-then-MAC

I prefer Encrypt-then-MAC: it's the least fragile.

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

iQIcBAEBCgAGBQJSwLhaAAoJEOyEjtkWi2t67yEQAIMwi3t7yBfCjjoYApgn9utK
RuD/ZZwYi9xSOQuK3WjVLfP/RS+iGJhZYV+2Ch5W3sG6qOUnYIEwTG7x+q5HUT1N
awwJwKqVekLIWXRT6DXiqNmso7niG2AWcA+qlzH3MvQp5HCsqr5Eem8cMcp2LaE2
iq/bBjZpE3XplIvi2+eoJko5yMoVMR/o/U9DHr/vo5LTCDh0vdiJmLVox3EQTYLZ
rZr/VmEom08FGY0R6sGIknKyeiwCpuje2sBBvwTnJ1YVUYgwrG3YXP9TWu2idEfs
haGtTWWib63ivoGQfiqvr/je5BQ/WmcRRNbY/PkSLk6L0PiO/2GxrwmxGA4KHrfe
+7Goa5+GZ6ZIefxNf/hH+uJhO9M5OsrMqmRljRtpFEIy7sEkFuNzZOaTlHfmvFC4
amC13eLND1cVuYN53Mb2R46MCiNK2vORyJk3hxejR2X9IYHSHvWT/asSJBo6x7fi
NG1andp7UuOOSjmcSJjcCJ2va3VeYwBNHaMaBGBCyQDLlrcvCQ4kQmrCvWkqUeVv
/MlN5oaeNYfR3URmURNuxqWpvkBNP8Q9VfmsCLII5SIEqRRFbaBTXjcws6PyoyQz
MnDAwYGaeQMa+oqGiVvg55wTRSddJgm3NHlKszT+IpRfh9aLl2uFRP6tLpn+wi7X
yMQwtt3fK80T86fWLveh
=1yCp
-----END PGP SIGNATURE-----

From alangley@gmail.com  Sun Dec 29 16:32:04 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB091AE34C for ; Sun, 29 Dec 2013 16:32:04 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 yOyDnRAbVD2Z for ; Sun, 29 Dec 2013 16:32:03 -0800 (PST)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id CE7BF1AE34B for ; Sun, 29 Dec 2013 16:32:02 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id w7so5205750lbi.38 for ; Sun, 29 Dec 2013 16:31:56 -0800 (PST)
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=qnbAPIK2q1HQxu7OrZpnMwaej5lHpZuitW1FGs87T7s=; b=d6M2xjd16DDpMX8UB/kSJLjUCHH8FNXGX6O0XQzbNUaIBiAbmQn37SosjllW+IdKEE Tu1r3LtdxKODwKCTSt7Jt6nMHqxPfx9i3BdmHd5y/wD641MvYCzmTtCRRXnUJVIfLTvD 1X2m6ui0Hu7l6U19d9uFdRRLd0OuJUEsVISMXhjwoWXAdJ2IFQXm2iwaOf2IBdtGsXWe s+zNnGtNXJ0swxswqk/q5PEMV8z57sMBSkALzYDj7HANVimgEnqmQQAhUomflG0s4QLM SaT8izF9hs9sGL6iAVHk+CjhIkQIk9TItf1ZSznJvsOxNb6XgtKJkYWLHrZk2VLu0c4E 0Cdg==
MIME-Version: 1.0
X-Received: by 10.152.6.201 with SMTP id d9mr13976924laa.25.1388363516528; Sun, 29 Dec 2013 16:31:56 -0800 (PST)
Sender: alangley@gmail.com
Received: by 10.112.162.200 with HTTP; Sun, 29 Dec 2013 16:31:56 -0800 (PST)
In-Reply-To: 
References: 
Date: Sun, 29 Dec 2013 19:31:56 -0500
X-Google-Sender-Auth: k9mwJu4Rbe_nbcjqIzjWfkztqz8
Message-ID: 
From: Adam Langley 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fixing CBC Mode I: GenericBlockCipher construction
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 00:32:04 -0000

On Sun, Dec 29, 2013 at 6:15 PM, Eric Rescorla  wrote:
> We have seen two major proposals for fixing the GenericBlockCipher
> construction:
>
> - Encrypt-then-MAC
> - Pad-MAC-Encrypt

I favor Encrypt-then-MAC.

(Would the new construction include a per-record IV in TLS 1.0?)


Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org

From alangley@gmail.com  Sun Dec 29 16:35:45 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595BE1AE354 for ; Sun, 29 Dec 2013 16:35:45 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 6o7_GUGwoNHC for ; Sun, 29 Dec 2013 16:35:44 -0800 (PST)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id A87FD1AE353 for ; Sun, 29 Dec 2013 16:35:43 -0800 (PST)
Received: by mail-la0-f49.google.com with SMTP id er20so5125532lab.8 for ; Sun, 29 Dec 2013 16:35:37 -0800 (PST)
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=kk0a8aIirtfjEviF4+ATcUNmI8VAXjmRtH0nh5FiC6A=; b=l/gHrLYWXVxeyiHdRYTkUo5Bu7UQeyzY+BUWY4hcTM4rvBAyfglIJG+fNxW/Oafz6F DHXwWTIJMSGZuFMAJNh2NP7YgXI1rfoudSFaT6GNpTkFFxdgh0aMz6y3Pu263xeRJO0J 0RLRrPA495UV3GjzGB4u35UeDXjkPPLkwHGbikY6dEB9oJ8vu0is+ppVz0sZ1W0izEZi +zDAbQNL/4spUTWXu6YkELuIhrOghz+DRfOC7qV5bj6J7Wii25BQfi7gB0WOvhyPIbLb vn496zYhpNPH/IHzznU8CQJR4KUwll3EuGeDKe/8I6t4lqUdN4Sqf1tvu3KYKk2lIKkG ULkQ==
MIME-Version: 1.0
X-Received: by 10.112.150.164 with SMTP id uj4mr10401843lbb.46.1388363737413;  Sun, 29 Dec 2013 16:35:37 -0800 (PST)
Sender: alangley@gmail.com
Received: by 10.112.162.200 with HTTP; Sun, 29 Dec 2013 16:35:37 -0800 (PST)
In-Reply-To: 
References: 
Date: Sun, 29 Dec 2013 19:35:37 -0500
X-Google-Sender-Auth: XfBEevLIEpcwe7JP71oSUUUPqOQ
Message-ID: 
From: Adam Langley 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fixing CBC Mode II: Indicating new GenericBlockCipher construction
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 00:35:45 -0000

On Sun, Dec 29, 2013 at 6:16 PM, Eric Rescorla  wrote:
> - Refusal to fall back below TLS 1.0 (which requires extension
>   tolerance)

Tried it in general in Chrome 31 and it was painful due to buggy,
local MITM proxies on Windows.

> - An ancillary anti-fallback mechanism, such as:
>   draft-bmoeller-tls-downgrade-scsv-01 (the requirement
>   here would likely be something like the server MUST support
>   this draft if they support the new CBC mode).

In ~3 months I hope to know whether
draft-bmoeller-tls-downgrade-scsv-01 is viable on a large scale. If it
turns out to be then the extension would be preferable as the SCSV
wouldn't be needed. I don't object to the SCSV if people wish to get
something done sooner.


Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org

From akr@akr.io  Sun Dec 29 16:41:33 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFB71AE34E for ; Sun, 29 Dec 2013 16:41:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level: 
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 10hxTqToKI4l for ; Sun, 29 Dec 2013 16:41:32 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 54AB61AE292 for ; Sun, 29 Dec 2013 16:41:32 -0800 (PST)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id 62BFA60185 for ; Mon, 30 Dec 2013 00:41:26 +0000 (GMT)
Message-ID: <52C0C149.3070001@akr.io>
Date: Mon, 30 Dec 2013 00:41:45 +0000
From: Alyssa Rowan 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Fixing CBC Mode II: Indicating new GenericBlockCipher construction
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 00:41:34 -0000

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

On 29/12/2013 23:16, Eric Rescorla wrote:

> We have seen two major proposals for indicating the use of a fixed
>  GenericBlockCipher construction:

> - Use a TLS Extension

I prefer the TLS Extension approach, combined with a required
anti-fallback mechanism: largely because I think we really need the
anti-fallback mechanism deployed (as urgently as I think we need to
deprecate RC4 as no longer suitable for any purpose!), and my
perception is that one security upgrade would be easier than two.

But agreed: I'm particularly interested in browser/server/endpoint
vendors' viewpoints about how practical that would be in real terms,
as that is where the challenge is likely to be.

And also, where the practicality problems are likely to arise: I think
that may indicate troublesome infrastructure that a nation state
adversary (or, indeed, any adversary, if the fruit is low-hanging
enough) would find particularly fruitful for attack (or at the least,
simply very convenient): and therefore, I think would warrant much
closer audit to see what else is likely to be up with it; and,
perhaps, ideas on how we could encourage more rapid deployment of fixes.

Bluesky thought on that note: Would, say, a BCP for TLS perhaps be
something we could potentially point standards bodies like PCI SSC to,
as a clear master reference for SSL/TLS to use to ensure 'the protocol
in use only supports secure versions or configurations' - and,
thereby, strongly encourage large, slow-moving sites that they _really
need_ to take action because they would face compliance problems if
they don't? Could that help?

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

iQIcBAEBCgAGBQJSwMFJAAoJEOyEjtkWi2t6qqIP/jSJdRHVtOvQgDc//fJB+Svz
6hFagrUiJCqb7kZRUgY+Bf5dsOWW9gOqJEJqjZHz8KzAfG2nuQkVAQWqggFhxlmn
bZz5LzEsalRTknefOb1322B+/buQmdeijRgcAjmvIpvXlHbbNjKVvcVtfz4QCNda
hPKd2h/rvS7qnxDc8NCSSyO6o0BUFEj3TZ2ru2TgvqSukRWodxAvmLUZeSK7xOva
OZ7YOWvMikpCoxx9+uflyQYPHyOnQcPEnEb15YGseeZmotX3HgpDyFFPOf5Sx8Z9
femzi1TaTyXeF1JC7NH0kh4kW3I/9ATCqevfBLCSqCwmhPTeHgIEv1npXJzpLhKy
mQTJyYspbaveFJU0elJOJaDfnUd0t+wcjz2xRrsRFON+QtALqNK49Y37SJwFwHYw
DEkLRyFJ5kQhH1SXcGyuWbR3wRzxAtYMQJ4pD5f9hQKkyQ/20aikTR+nfX3i9aVw
LadcEGZPcLYgJimDghD29LYgZdjPFedolfLvI88e51XhgDmk0QaCjcjR69V2mR/o
JuWFOWJIhnjW9YlzZstaBbWkxeeM095CIh6g93qYZZWg7vmiE08E0NW6/ETE+Gui
Dzery0wqYtXnCjflv3x6/dKasn9+kZjVl+9z82kkQhh0EknVRA3YpidzD0dHcy+X
ZXx3QlMsp7llcqu9+ysk
=JMqm
-----END PGP SIGNATURE-----

From ekr@rtfm.com  Sun Dec 29 16:59:07 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B7D1AE317 for ; Sun, 29 Dec 2013 16:59:07 -0800 (PST)
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 BjVgHi2fg9ES for ; Sun, 29 Dec 2013 16:59:06 -0800 (PST)
Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7171AE226 for ; Sun, 29 Dec 2013 16:59:06 -0800 (PST)
Received: by mail-we0-f175.google.com with SMTP id t60so9603058wes.20 for ; Sun, 29 Dec 2013 16:59:00 -0800 (PST)
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=cASLeriZFSp6tVP9jjxucbltySLZ2nYpFfTW8oYg8Pg=; b=RrBagQ3evjFylx2bJTxsBwpsRl/KMuEHFlRvAL0uhePfLxmHP0/oKTBVCv0a4uasMZ KzfD7qVzRbo8z3jcT4SDUaU6qlarjFn0Nw4xmoc6T2T3rN11xEmpcgkLWAmwnaUlkm27 vrioQsyXhiHymBr0+Ok5gOgOyLmE9bzRUC+tVgb43sfAzk7aY/iKv+7HrPPalyaDyMsw NBBXGXI9wsVFr4iklGO7nE4LHOBvUGKjRydXvzFlQQ12sfuYz55jfTm06SxOPRIrtySI jPEP/vSzxMDqStxUmnLLEo5SBHFa7a251al8StTDBF/j4i5WmFIVX1JDN3lVK1MXxWfx uGog==
X-Gm-Message-State: ALoCoQlwzWkOX2hGogYZo2IKCywNsPG/zdXm5Md/mf5Ir0FXnp6EiMZsllNKtMm4+jEBeRm3anqs
X-Received: by 10.180.189.106 with SMTP id gh10mr42093705wic.18.1388365139940;  Sun, 29 Dec 2013 16:58:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Sun, 29 Dec 2013 16:58:19 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: 
References:  
From: Eric Rescorla 
Date: Sun, 29 Dec 2013 16:58:19 -0800
Message-ID: 
To: Adam Langley 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fixing CBC Mode I: GenericBlockCipher construction
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 00:59:07 -0000

On Sun, Dec 29, 2013 at 4:31 PM, Adam Langley  wrote:
> On Sun, Dec 29, 2013 at 6:15 PM, Eric Rescorla  wrote:
>> We have seen two major proposals for fixing the GenericBlockCipher
>> construction:
>>
>> - Encrypt-then-MAC
>> - Pad-MAC-Encrypt
>
> I favor Encrypt-then-MAC.
>
> (Would the new construction include a per-record IV in TLS 1.0?)

Peter's current draft does not include this change.

Speaking for myself I would prefer we not do so, since that's
already in TLS 1.1 and TLS 1.2 and so we should be focusing
here on the minimal change.

-Ekr

From watsonbladd@gmail.com  Sun Dec 29 18:37:49 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6921AE387 for ; Sun, 29 Dec 2013 18:37:49 -0800 (PST)
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 2Kbq2kPiVSgB for ; Sun, 29 Dec 2013 18:37:48 -0800 (PST)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id ADFC81AE383 for ; Sun, 29 Dec 2013 18:37:47 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id q58so9637821wes.19 for ; Sun, 29 Dec 2013 18:37:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o0ZpDftJvM/behXKTRlN1FFTMdcqmWvDCpJWAhLEoeI=; b=sV1nHId4LxTGMUsRujBCY919gjkylr0d6+u9SpaTS3T2GyHjqxaPQG5C72l0PUnHvu E10GvYCTHO9UiEU9i8SQgI75S6WHNMEisqDWlC9bOWq+oSo6suMMAiszBzJWKxI7NT5n r9BPSQwKPxDPXu5W+aFdRKPjMbCKrV2kEx4yTFs+3Ufw80H6o2QULDbmSnmrPFrgmzSy yVL6pmYsbTbwXNsOaNuy7MttquQpsfO+rLVRU0DXdzHm+hg3U84XJWEQ1EX5K8dEpeID yldey1kIorkX6xFnTFOnEw9uOeHP3hgPzPDo9M3EMIdkaJ6r32ZFD3egHX6WNLT3lyAe yYwA==
MIME-Version: 1.0
X-Received: by 10.180.13.242 with SMTP id k18mr42097654wic.44.1388371061377; Sun, 29 Dec 2013 18:37:41 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Sun, 29 Dec 2013 18:37:41 -0800 (PST)
In-Reply-To: <52C0C149.3070001@akr.io>
References:  <52C0C149.3070001@akr.io>
Date: Sun, 29 Dec 2013 21:37:41 -0500
Message-ID: 
From: Watson Ladd 
To: Alyssa Rowan 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fixing CBC Mode II: Indicating new GenericBlockCipher construction
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 02:37:50 -0000

On Sun, Dec 29, 2013 at 7:41 PM, Alyssa Rowan  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 29/12/2013 23:16, Eric Rescorla wrote:
>
>> We have seen two major proposals for indicating the use of a fixed
>>  GenericBlockCipher construction:
>
>> - Use a TLS Extension
>
> I prefer the TLS Extension approach, combined with a required
> anti-fallback mechanism: largely because I think we really need the
> anti-fallback mechanism deployed (as urgently as I think we need to
> deprecate RC4 as no longer suitable for any purpose!), and my
> perception is that one security upgrade would be easier than two.
>
> But agreed: I'm particularly interested in browser/server/endpoint
> vendors' viewpoints about how practical that would be in real terms,
> as that is where the challenge is likely to be.
>
> And also, where the practicality problems are likely to arise: I think
> that may indicate troublesome infrastructure that a nation state
> adversary (or, indeed, any adversary, if the fruit is low-hanging
> enough) would find particularly fruitful for attack (or at the least,
> simply very convenient): and therefore, I think would warrant much
> closer audit to see what else is likely to be up with it; and,
> perhaps, ideas on how we could encourage more rapid deployment of fixes.
>
> Bluesky thought on that note: Would, say, a BCP for TLS perhaps be
> something we could potentially point standards bodies like PCI SSC to,
> as a clear master reference for SSL/TLS to use to ensure 'the protocol
> in use only supports secure versions or configurations' - and,
> thereby, strongly encourage large, slow-moving sites that they _really
> need_ to take action because they would face compliance problems if
> they don't? Could that help?

The BCP you are looking for was sent to UTA WG instead, and they've
done nothing with it.
The author has no clue what is holding it up.
>
> - --
> /akr
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJSwMFJAAoJEOyEjtkWi2t6qqIP/jSJdRHVtOvQgDc//fJB+Svz
> 6hFagrUiJCqb7kZRUgY+Bf5dsOWW9gOqJEJqjZHz8KzAfG2nuQkVAQWqggFhxlmn
> bZz5LzEsalRTknefOb1322B+/buQmdeijRgcAjmvIpvXlHbbNjKVvcVtfz4QCNda
> hPKd2h/rvS7qnxDc8NCSSyO6o0BUFEj3TZ2ru2TgvqSukRWodxAvmLUZeSK7xOva
> OZ7YOWvMikpCoxx9+uflyQYPHyOnQcPEnEb15YGseeZmotX3HgpDyFFPOf5Sx8Z9
> femzi1TaTyXeF1JC7NH0kh4kW3I/9ATCqevfBLCSqCwmhPTeHgIEv1npXJzpLhKy
> mQTJyYspbaveFJU0elJOJaDfnUd0t+wcjz2xRrsRFON+QtALqNK49Y37SJwFwHYw
> DEkLRyFJ5kQhH1SXcGyuWbR3wRzxAtYMQJ4pD5f9hQKkyQ/20aikTR+nfX3i9aVw
> LadcEGZPcLYgJimDghD29LYgZdjPFedolfLvI88e51XhgDmk0QaCjcjR69V2mR/o
> JuWFOWJIhnjW9YlzZstaBbWkxeeM095CIh6g93qYZZWg7vmiE08E0NW6/ETE+Gui
> Dzery0wqYtXnCjflv3x6/dKasn9+kZjVl+9z82kkQhh0EknVRA3YpidzD0dHcy+X
> ZXx3QlMsp7llcqu9+ysk
> =JMqm
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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 watsonbladd@gmail.com  Sun Dec 29 19:32:59 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB841AE392 for ; Sun, 29 Dec 2013 19:32:59 -0800 (PST)
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 96_18DHeS9CN for ; Sun, 29 Dec 2013 19:32:58 -0800 (PST)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BFA271AE0EF for ; Sun, 29 Dec 2013 19:32:57 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id hq4so15282565wib.1 for ; Sun, 29 Dec 2013 19:32:51 -0800 (PST)
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=KvM6neFwNDI17t3c9x1ba96zjE4nLpRY4bM35LdbFeY=; b=gRxcNcc5ZG7SFqgvwVpACak5pds/fI1P4oATPbgB8T8tRSxYCmDvxrFCBHvtorfW6M ZgDUMZ9QSBnIKg39i/Aazvx51CL/W2oqPgCBnFEkQJGq+KnM1sMQOdr6mszUp02FaltR cUcU2pHeqtcHnn7lzMr7EH5prec3pj32zIVZ0omj024f9XosmSngL39HCbGLHblB+dk8 kt7HEEs92ohotRYXUJgAW02hpNBIfO0hHBm+BpwhGT3WnEJx/JRp9kzzZwBP1qNWKbt9 Fth4OAte9n8lxVPqFviobsIuEQvtPiulW956Vdylac+0DaZhMs3+88fsxqaoge2QbcoZ D8ng==
MIME-Version: 1.0
X-Received: by 10.180.90.230 with SMTP id bz6mr38574864wib.17.1388374371486; Sun, 29 Dec 2013 19:32:51 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Sun, 29 Dec 2013 19:32:51 -0800 (PST)
Date: Sun, 29 Dec 2013 22:32:51 -0500
Message-ID: 
From: Watson Ladd 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Subject: [TLS] Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 03:32:59 -0000

Dear all,

A short draft telling us what we all should be doing anyway? No
extensions required, just banishing the RC4 ciphersuites to the place
they belong.
All TLS implementations include other ciphers, so there isn't much of
an interop issue here AFAIK. Several implementations have already made
this change, so I think we should officially bless it. Even if later
BCP's reiterate the advice, there isn't harm in restating it.

If people have other opinions I would be interested in hearing them.

Sincerely,
Watson Ladd

From ynir@checkpoint.com  Mon Dec 30 01:35:34 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE541AE296 for ; Mon, 30 Dec 2013 01:35:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.439
X-Spam-Level: 
X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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-Qdqs2IdU9p for ; Mon, 30 Dec 2013 01:35:30 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EC1C31AE290 for ; Mon, 30 Dec 2013 01:35:29 -0800 (PST)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rBU9ZLUI007810; Mon, 30 Dec 2013 11:35:21 +0200
X-CheckPoint: {52C139AE-0-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.77]) by IL-EX10.ad.checkpoint.com ([169.254.2.82]) with mapi id 14.03.0123.003; Mon, 30 Dec 2013 11:35:21 +0200
From: Yoav Nir 
To: Eric Rescorla 
Thread-Topic: [TLS] Fixing CBC Mode I: GenericBlockCipher construction
Thread-Index: AQHPBOwHfLildINVmkCY5rvVSqBxM5psWYuA
Date: Mon, 30 Dec 2013 09:35:20 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.79]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <58F370B7810A0A49A74E49568A9C9601@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fixing CBC Mode I: GenericBlockCipher construction
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 09:35:35 -0000

On Dec 30, 2013, at 1:15 AM, Eric Rescorla  wrote:

> We have seen two major proposals for fixing the GenericBlockCipher
> construction:
>=20
> - Encrypt-then-MAC
> - Pad-MAC-Encrypt

I prefer Encrypt-then-MAC  (or rather Pad-Encrypt-Mac)

This has been used in IPsec for as long as there's been IPsec, and has not =
been broken.=20

It has the desirable property that spoofed or modified packets can be detec=
ted more quickly, as only the MAC function needs to be run for such detecti=
on. With P-M-E the receiver has to decrypt and calculate the MAC to identif=
y a modified packet. This does mean that we should be careful with the MAC =
functions that they don't leak information through side channel, but that i=
s a property that we require of MAC functions anyway.

Yoav


From ynir@checkpoint.com  Mon Dec 30 01:38:00 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8231AE290 for ; Mon, 30 Dec 2013 01:38:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.439
X-Spam-Level: 
X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 RyXuLOw82q6e for ; Mon, 30 Dec 2013 01:37:59 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E47FD1AE2B8 for ; Mon, 30 Dec 2013 01:37:58 -0800 (PST)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rBU9bSdG008357; Mon, 30 Dec 2013 11:37:48 +0200
X-CheckPoint: {52C13A2E-0-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.77]) by IL-EX10.ad.checkpoint.com ([169.254.2.82]) with mapi id 14.03.0123.003; Mon, 30 Dec 2013 11:37:28 +0200
From: Yoav Nir 
To: Adam Langley 
Thread-Topic: [TLS] Fixing CBC Mode I: GenericBlockCipher construction
Thread-Index: AQHPBOwHfLildINVmkCY5rvVSqBxM5prwbcAgACYbIA=
Date: Mon, 30 Dec 2013 09:37:27 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.79]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <03AEAD5E2B22354888946648B7E6616A@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fixing CBC Mode I: GenericBlockCipher construction
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 09:38:00 -0000

On Dec 30, 2013, at 2:31 AM, Adam Langley  wrote:

> On Sun, Dec 29, 2013 at 6:15 PM, Eric Rescorla  wrote:
>> We have seen two major proposals for fixing the GenericBlockCipher
>> construction:
>>=20
>> - Encrypt-then-MAC
>> - Pad-MAC-Encrypt
>=20
> I favor Encrypt-then-MAC.
>=20
> (Would the new construction include a per-record IV in TLS 1.0?)

If you do that, I think you pretty much have TLS 1.1.

So no, I think any implementation that adds this should also have TLS 1.1. =
No, they should add TLS 1.1 even if they don't (yet) implement this.

Yoav


From ynir@checkpoint.com  Mon Dec 30 01:50:43 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758AB1AE257 for ; Mon, 30 Dec 2013 01:50:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.439
X-Spam-Level: 
X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 CFSfAloufOSX for ; Mon, 30 Dec 2013 01:50:42 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 02B981AE202 for ; Mon, 30 Dec 2013 01:50:41 -0800 (PST)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rBU9oWOZ011979; Mon, 30 Dec 2013 11:50:32 +0200
X-CheckPoint: {52C13D3D-E-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.77]) by IL-EX10.ad.checkpoint.com ([169.254.2.82]) with mapi id 14.03.0123.003; Mon, 30 Dec 2013 11:50:32 +0200
From: Yoav Nir 
To: Watson Ladd 
Thread-Topic: [TLS] Remarks on draft-popov-prohibiting-rc4-01
Thread-Index: AQHPBQ/Z648qNZDIh0SFD+5BwyS5c5psXYKA
Date: Mon, 30 Dec 2013 09:50:32 +0000
Message-ID: <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.79]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 09:50:43 -0000

My only issue with this, is that clients and servers have to deal with the =
installed base, and the installed base includes IE6 running on XP, several =
older versions of Safari on outdated OSX, Firefox 3.6, and thousands of web=
 servers running anything you can think of.

So if you take away RC4, you still have to support CBC ciphersuites for 3DE=
S (maybe AES would work most of the time=85) without the modification being=
 discussed in another thread.

So given the choice between RC4 and 3DES-CBC without P-E-M and without fanc=
y 1-byte-record BEAST mitigation, which would you prefer?

Yoav

On Dec 30, 2013, at 5:32 AM, Watson Ladd  wrote:

> Dear all,
>=20
> A short draft telling us what we all should be doing anyway? No
> extensions required, just banishing the RC4 ciphersuites to the place
> they belong.
> All TLS implementations include other ciphers, so there isn't much of
> an interop issue here AFAIK. Several implementations have already made
> this change, so I think we should officially bless it. Even if later
> BCP's reiterate the advice, there isn't harm in restating it.
>=20
> If people have other opinions I would be interested in hearing them.
>=20
> Sincerely,
> Watson Ladd



From yaronf.ietf@gmail.com  Mon Dec 30 02:57:04 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451DB1ADFA6 for ; Mon, 30 Dec 2013 02:57:04 -0800 (PST)
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 96cewl8Ic2cL for ; Mon, 30 Dec 2013 02:57:03 -0800 (PST)
Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BE6881ADF71 for ; Mon, 30 Dec 2013 02:57:02 -0800 (PST)
Received: by mail-ea0-f175.google.com with SMTP id z10so4979145ead.20 for ; Mon, 30 Dec 2013 02:56:56 -0800 (PST)
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=NJLZtDUiQqNipqAcEe9ejAzEd79DUHj7elF3r3xTjWk=; b=q7j1UxpMyesnanAx0nPdYzWn+FPCE2VihSLhJ3kzYGkfIXF2DcKWY5EK6Devf0VP2V HQzSY0aT11LDgGoRtah/fQrHz6jXVY2dNuH3rgnXRYOMJxvdjc8JOFQdCNCZgbZu4+pG SMvMRP783nTVaD4E42hTdrRlnH5tHZrnAYHWJUozACaf9I5FNanAgLWROCqUiMNmGS2O 6EsyyqtBSzJ4mpleuEmaiqUETtlU/FaZBoA4M3XJX65FKaKwnjfdlMugU4WQA+KJmV0X tcky2ZPnBc6kg7VObVfjKdw1vqzIxCmLRpll4NvFJgyaLeFNrgpeuYdjGjK7BeUyVkEN T8PA==
X-Received: by 10.15.54.130 with SMTP id t2mr1018334eew.72.1388401016491; Mon, 30 Dec 2013 02:56:56 -0800 (PST)
Received: from [10.0.0.10] (85-250-7-219.bb.netvision.net.il. [85.250.7.219]) by mx.google.com with ESMTPSA id z42sm107538678eeo.17.2013.12.30.02.56.55 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Dec 2013 02:56:55 -0800 (PST)
Message-ID: <52C15176.4000307@gmail.com>
Date: Mon, 30 Dec 2013 12:56:54 +0200
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Watson Ladd , Alyssa Rowan 
References:  <52C0C149.3070001@akr.io> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fixing CBC Mode II: Indicating new GenericBlockCipher construction
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 10:57:04 -0000

>
> The BCP you are looking for was sent to UTA WG instead, and they've
> done nothing with it.
> The author has no clue what is holding it up.
>>

Hi Watson,

The said BCP (https://ietf.org/doc/draft-sheffer-tls-bcp/) is in fact 
waiting for the newly formed UTA working group to adopt it formally. 
This WG has not published yet a list of deliverables. In fact, there is 
nothing extraordinary about this process delay, especially given the 
holiday period.

Thanks,
	Yaron

From ynir@checkpoint.com  Mon Dec 30 03:12:14 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6411AE4EA for ; Mon, 30 Dec 2013 03:12:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.439
X-Spam-Level: 
X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 10skIuWimA5t for ; Mon, 30 Dec 2013 03:12:13 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A96481ADF60 for ; Mon, 30 Dec 2013 03:12:12 -0800 (PST)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rBUBC5Bc002815; Mon, 30 Dec 2013 13:12:06 +0200
X-CheckPoint: {52C15059-1F-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.77]) by IL-EX10.ad.checkpoint.com ([169.254.2.82]) with mapi id 14.03.0123.003; Mon, 30 Dec 2013 13:12:05 +0200
From: Yoav Nir 
To: Eric Rescorla 
Thread-Topic: [TLS] Fixing CBC Mode II: Indicating new GenericBlockCipher construction
Thread-Index: AQHPBOwiUZI8c/2X9EmRL7PObVmcFppsdI+A
Date: Mon, 30 Dec 2013 11:12:04 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.79]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fixing CBC Mode II: Indicating new GenericBlockCipher	construction
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 11:12:14 -0000

On Dec 30, 2013, at 1:16 AM, Eric Rescorla  wrote:

> WG Members,
>=20
> We have seen two major proposals for indicating the use of a fixed
> GenericBlockCipher construction:
>=20
> - Use a TLS Extension
> - Use an SCSV

I may be missing something, but you anyway need an extension for the server=
 to signal to the client that it agrees to the use of a fixed GenericBlockC=
ipher, no?

So the actual question is not whether to use an SCSV or an extension, but w=
hether to define and SCSV *in addition to* the extension (as in RI) or to f=
orego it (as in every other TLS extension ever)

I would go with an extension only, and here's why:
An extension-intolerant server is not going to emit the server hello extens=
ion either, and it not going to support this extension either. Browsers tod=
ay emit many extensions, so an extension-intolerant server is going to forc=
e a downgrade anyway.
Extension-intolerant middleware will force the client to drop the extension=
s. If the client persists in sending the SCSV, the middleware may miss it a=
nd forward the ClientHello to the server. In that case, the server will rep=
ly with an extension, that the middleware will drop. Besides, with an SCSV =
we have to deal with this:
 Client                  Server
CH with extensiosn -->
       <--- RST
CH without extensions but with SCSV
          ----------->
       <--- SH with extension

I guess Yngve will tell us that this is a way (for the server) to detect a =
downgrade attack.

But I don't see where an SCSV will give us any benefit.

Yoav=

From akr@akr.io  Mon Dec 30 04:01:45 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F2D1ADFA6 for ; Mon, 30 Dec 2013 04:01:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level: 
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 UFJ6NGX1OYeV for ; Mon, 30 Dec 2013 04:01:42 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 920721ADF7E for ; Mon, 30 Dec 2013 04:01:42 -0800 (PST)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id 5999F60361 for ; Mon, 30 Dec 2013 12:01:35 +0000 (GMT)
Message-ID: <52C160B4.10103@akr.io>
Date: Mon, 30 Dec 2013 12:01:56 +0000
From: Alyssa Rowan 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tls@ietf.org
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com>
In-Reply-To: <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 12:01:45 -0000

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

On 30/12/2013 09:50, Yoav Nir wrote:
> My only issue with this, is that clients and servers have to deal 
> with the installed base, and the installed base includes IE6 
> running on XP, several older versions of Safari on outdated OSX, 
> Firefox 3.6, and thousands of web servers running anything you can
>  think of.

Then the installed base *requires* an update: it can no longer connect
securely, and transport layer _security's_ job is to not be insecure.
Inertia can only go so far, but at some point, we _have_ to rip the
plaster off. We don't support export-mode anymore, do we?

I'd push for removing RC4 support _completely_ - and 3DES-CBC to have
a security warning and not supported unless you really want to support
legacy clients. I'd begrudgingly support good old AES-128-CBC w/ SHA
in TLS v1.0 for legacy (and no MD5 or MD2 at all, either).

I'd want EV (green-bar) server requirements to require full compliance
with draft-sheffer-tls-bcp (or whatever it becomes). I'd suggest
TLSv1.2 AES-GCM as a minimum, and probably also (going forward)
ChaCha20_Poly1305 support - and downgrade protection, when we can get
it out there. Also SHA-256 rather than SHA-1.

RC4 is broken. It is unsuitable for any purpose - and that's what we
know as civilians. You should no more use RC4 in 2014 than you should
be using the 40-bit "export-mode" ciphers: please turn it off!

NSA/GCHQ found it extremely convenient (maybe _too_ convenient) that
people were using RC4 to mitigate BEAST.

They also warned that the 'cryptologic breakthrough', though
convenient, was temporary and fragile (i.e. people would soon be
advised to stop using it - which is of course what we are discussing
here!).

Tentative conclusion: Whatever break the NSA/GCHQ have for RC4 is
worse than BEAST - possibly even plaintext-recovery in real-time or
near-real-time?! Whatever it is, they were _joking_ about its
security, or lack thereof.

I think RC4, and the CA model as it currently stands, are TLS's
biggest security issues re: perpass, and in general. RC4 is definitely
the easier one to fix: we turn it off.

Let's remember the broader picture too: XP goes EOL in April, and this
could well result in a flurry of 0days (deliberately held back until
after EOL) that will probably not be patched. Possible result: open
season on internet worms, maybe something along the scale of NIMDA or
Sapphire. Continuing to support an insecure IE6 even in the face of
that seems optimistic.

Of course, that's only my insignificant viewpoint; and what I'd like
may be infeasible in the short-term. I'm aware that inertia can be a
tricky point: probably one of the biggest challenges for TLS.

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

iQIcBAEBCgAGBQJSwWCzAAoJEOyEjtkWi2t6ZvoQALCNhJgXVz/sCCGw2UCiH44m
XFWiIJvsSn0+I86LNmK829YAzhfh9EkdZq+jYLZyxo3cgfZ1pApuE3TqmkW6vPwa
62cO/KhZpKG9sIuCVVEZcDjczzPBtRq2S/W/x1oPSXec7ldV1VOuf7Bs3WlzXbfp
4M4uoc01LLL/viWX69hFKcgFacSG/+iSKo4gRUYUfIMKoupe1DdfOlvUgrPQ0Pfc
swebA78zqCy0yssYwHMgkzTP+QCSAsR0kgmFkN5og5howJk8RR79v4oxq92sgv19
ygsDPtFs+5R8K0+cQdKzv7F5JRMSDOXDll1IxfO9Y13dUtMixv6ZMJrtvBLDLvmV
N3JiQMIJVTHCu/m07hcaMx73fYijxK5lE6XMatJlbM+cNplSRoVanmXV5KNs/nol
b18L4dHPriXFsMyaE3lISTgqSsYTWpRiRBRDdA3/5uBKaNYrX90mmNzdkfIc1ZMp
F/ORzW6Jt+G1RH6pnvDuzfXeNMt3vO4vKhnQ3yKaHTFk2H2NJscgC3RPt1ggrBQT
Kz1CS6r3qEppiFFZYkxWXZnBuzq5QBT94pNatHxmUMHMbRxmGjlDmaC+5Kv4dpr6
hu9HlGaKL51dzCVS0I3sqoMqJ6eT853ise1UJMpRO/7CLW9D+sP8cjMPawBYB8/5
BuNpUGT+SLXeflBPHe1d
=ObTs
-----END PGP SIGNATURE-----

From watsonbladd@gmail.com  Mon Dec 30 04:48:40 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E3A1AE0B9 for ; Mon, 30 Dec 2013 04:48:40 -0800 (PST)
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 lmo5SX7Pspsh for ; Mon, 30 Dec 2013 04:48:38 -0800 (PST)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AF67C1AE061 for ; Mon, 30 Dec 2013 04:48:37 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id a1so9939951wgh.11 for ; Mon, 30 Dec 2013 04:48:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/QwDL8ddIOkWE3axuIz8erVDd1x5i7xDDCjgX5TkJL4=; b=YsovnQWr4XiyxVZeKP6AtvQh5hVJFZKLT+tr0QUAUx2PC2SFD0c4PJaQFJPHHaDmvJ takr0QKYGtGQPK9Z2WxRsWGoMj6Vz9bRZoKVvFeDqgZhuo/bpjo5yyuk5GQXOlUXFS/4 GC1948//yT4SaiMJmCOhawGcOEAYSpsL38YYC5aX0XF18EX5BmPv+Wy5utYRhCYvSwVJ 9xY5G2d6pY9SpGxwWQkLZ+UZ7PCk6pTiYyPpsWQm7xLL6JuSIK2ft897gfNXnEmYXFq8 fiSPoHGQnzmRqYmL+njxlfifbn6oCLSQ9LRFT9ZySV1kvURp/DGbjV7eoONlcHEK7u4E jERg==
MIME-Version: 1.0
X-Received: by 10.194.189.132 with SMTP id gi4mr41441183wjc.5.1388407711511; Mon, 30 Dec 2013 04:48:31 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 30 Dec 2013 04:48:31 -0800 (PST)
In-Reply-To: <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com>
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com>
Date: Mon, 30 Dec 2013 07:48:31 -0500
Message-ID: 
From: Watson Ladd 
To: Yoav Nir 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 12:48:40 -0000

On Mon, Dec 30, 2013 at 4:50 AM, Yoav Nir  wrote:
> My only issue with this, is that clients and servers have to deal with th=
e installed base, and the installed base includes IE6 running on XP, severa=
l older versions of Safari on outdated OSX, Firefox 3.6, and thousands of w=
eb servers running anything you can think of.
>
> So if you take away RC4, you still have to support CBC ciphersuites for 3=
DES (maybe AES would work most of the time=E2=80=A6) without the modificati=
on being discussed in another thread.
>
> So given the choice between RC4 and 3DES-CBC without P-E-M and without fa=
ncy 1-byte-record BEAST mitigation, which would you prefer?

3DES-CBC. BEAST requires the ability to inject data on record
boundaries, and 3DES attacks are chosen-plaintext. Given that IE6
doesn't
support the new features that permit such an injection, it's not my
favorite thing in the world, but better than RC4.

RC4 has lots more problems: we don't know what they are because until
recently everyone in academia thought no one was using it.
Jacob Appelbaum is saying it can "read" but he's not provided the
documentation to back that one up. It is however worrying that
every time someone graphs something from RC4, we get a pretty graph.

Sincerely,
Watson Ladd

>
> Yoav
>
> On Dec 30, 2013, at 5:32 AM, Watson Ladd  wrote:
>
>> Dear all,
>>
>> A short draft telling us what we all should be doing anyway? No
>> extensions required, just banishing the RC4 ciphersuites to the place
>> they belong.
>> All TLS implementations include other ciphers, so there isn't much of
>> an interop issue here AFAIK. Several implementations have already made
>> this change, so I think we should officially bless it. Even if later
>> BCP's reiterate the advice, there isn't harm in restating it.
>>
>> If people have other opinions I would be interested in hearing them.
>>
>> Sincerely,
>> Watson Ladd
>
>



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

From ekr@rtfm.com  Mon Dec 30 06:00:36 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A3F1AE105 for ; Mon, 30 Dec 2013 06:00:36 -0800 (PST)
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 4pTChrmuzRVv for ; Mon, 30 Dec 2013 06:00:35 -0800 (PST)
Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id E788A1AE0B9 for ; Mon, 30 Dec 2013 06:00:34 -0800 (PST)
Received: by mail-we0-f178.google.com with SMTP id u57so10266166wes.9 for ; Mon, 30 Dec 2013 06:00:28 -0800 (PST)
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:content-transfer-encoding; bh=eKUT+z81+t7ksGEckTw1Ysww/TQR3f2XPRBlZMxF0NU=; b=Fm7Qqgo+eXwFXp5eDSiAUW60vYegTKxf+Zg0F9ytuCH/azry5OgYPPND7+NUr7dhuE nKXRSadnHeoXNx3VKBcJF0H4bHEpgN+MH6zhybBdHtAWLdRs0eTueOP3R4f/VvuDrk1a gndIH5z4nM0n4pB6x7W3ALSQEHudaLC7aSWQKAuISQ24DB3lCGHhufn9bmTHyBpsmlq7 tJKX7w6Kh3rglRqzvAZa2oIDwNV58s3S+kwpu/XElOmm0Bf3pyP52cUOu7oZQ61QTuTn Lm1ovPHZ/30zaeK6Ut0Ju+3SkJ07GlUZS13sU+WZw+501xtBV0lyOPzYLxnsjurfbgMk 1akg==
X-Gm-Message-State: ALoCoQmuvyV8wqWOQdwaCUvWilhzhdBuh8ZUebFoF9VH1Zbu4hEq3gksCTrHtd0WSkZ+cmi9nldH
X-Received: by 10.194.21.225 with SMTP id y1mr20540595wje.60.1388412027975; Mon, 30 Dec 2013 06:00:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Mon, 30 Dec 2013 05:59:47 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: 
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> 
From: Eric Rescorla 
Date: Mon, 30 Dec 2013 05:59:47 -0800
Message-ID: 
To: Watson Ladd 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 14:00:36 -0000

On Mon, Dec 30, 2013 at 4:48 AM, Watson Ladd  wrote:
> On Mon, Dec 30, 2013 at 4:50 AM, Yoav Nir  wrote:
>> My only issue with this, is that clients and servers have to deal with t=
he installed base, and the installed base includes IE6 running on XP, sever=
al older versions of Safari on outdated OSX, Firefox 3.6, and thousands of =
web servers running anything you can think of.
>>
>> So if you take away RC4, you still have to support CBC ciphersuites for =
3DES (maybe AES would work most of the time=85) without the modification be=
ing discussed in another thread.
>>
>> So given the choice between RC4 and 3DES-CBC without P-E-M and without f=
ancy 1-byte-record BEAST mitigation, which would you prefer?
>
> 3DES-CBC. BEAST requires the ability to inject data on record
> boundaries, and 3DES attacks are chosen-plaintext. Given that IE6
> doesn't
> support the new features that permit such an injection, it's not my
> favorite thing in the world, but better than RC4.

Not to disagree with the main point that we should be more interested
in removing RC4, but what Web browser features do you believe are
required to mount attacks on CBC cipher suites?

-Ekr

From watsonbladd@gmail.com  Mon Dec 30 07:20:47 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314801AE18E for ; Mon, 30 Dec 2013 07:20:47 -0800 (PST)
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 QaVkBSl3OEmC for ; Mon, 30 Dec 2013 07:20:44 -0800 (PST)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE511ADF4F for ; Mon, 30 Dec 2013 07:20:44 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id u56so9924952wes.8 for ; Mon, 30 Dec 2013 07:20:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+p5rYNPBs3097C3eBHZYH7K/eOXU1+3lwAHG9+KO8VM=; b=qD12W4XupcR/A0zvvZnQrKLWE7zA1DKIcDc1DwsondegU4NewtSuqgJmC+LYxaIuSE 20da/wD+U3yp6EWtWrrUW4kKKtHOuFL3Pb0IZ6JFnCXB+vBEpw+u+jiqPj4esgooy9lW C4Ydz77Vbq2rWYGqpaRxqs+46qg/6VPO3iw9l9i22sRUB3Qma+QUjnFczEwxq4CmfR4R 58UlXSDzZzwhTkVBh8l/BRNDFGBcbyPUmwzQq+oNj2XihDyNhAsFgFP7ttW5oxnQRmhQ oLNYZd7Ng69UYLSioyUoFYKGRwQi9Dkdlf0LmFBE24kktC/coVsYa6LdSxdJxs2lCEIg 5E4w==
MIME-Version: 1.0
X-Received: by 10.180.86.9 with SMTP id l9mr44388457wiz.20.1388416838146; Mon, 30 Dec 2013 07:20:38 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 30 Dec 2013 07:20:38 -0800 (PST)
In-Reply-To: 
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com>  
Date: Mon, 30 Dec 2013 10:20:38 -0500
Message-ID: 
From: Watson Ladd 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 15:20:47 -0000

On Mon, Dec 30, 2013 at 8:59 AM, Eric Rescorla  wrote:
> On Mon, Dec 30, 2013 at 4:48 AM, Watson Ladd  wrot=
e:
>> On Mon, Dec 30, 2013 at 4:50 AM, Yoav Nir  wrote:
>>> My only issue with this, is that clients and servers have to deal with =
the installed base, and the installed base includes IE6 running on XP, seve=
ral older versions of Safari on outdated OSX, Firefox 3.6, and thousands of=
 web servers running anything you can think of.
>>>
>>> So if you take away RC4, you still have to support CBC ciphersuites for=
 3DES (maybe AES would work most of the time=E2=80=A6) without the modifica=
tion being discussed in another thread.
>>>
>>> So given the choice between RC4 and 3DES-CBC without P-E-M and without =
fancy 1-byte-record BEAST mitigation, which would you prefer?
>>
>> 3DES-CBC. BEAST requires the ability to inject data on record
>> boundaries, and 3DES attacks are chosen-plaintext. Given that IE6
>> doesn't
>> support the new features that permit such an injection, it's not my
>> favorite thing in the world, but better than RC4.
>
> Not to disagree with the main point that we should be more interested
> in removing RC4, but what Web browser features do you believe are
> required to mount attacks on CBC cipher suites?

You need to be able to inject chosen-plaintext with a high degree of
control into an existing TLS connection.
The BEAST demo used Java, but Websockets was also vulnerable. The AJAX
stuff hasn't be used to the
best of my knowledge to mount this attack: there is enough junk before
what the attack controls to make
life difficult. There is a reason it was ~9 years between the papers
explaining the issue and a demo.

Lucky 13 and friends can be mounted anyway, but if the connection is
torn down on padding error it takes a while
to have any luck.

The problem however is we have remediations for BEAST and Lucky 13 in
modern browsers, but not RC4.
RC4 does not get negotiated only for IE6 on XP: 36.2% of sites
SSLPulse surveyed use it with modern browsers.
Worst case, we might be feeding IE6 on XP to the wolves in order to
protect everyone else.

I understand this is going to be EOL in a few months, so I don't feel
bound to be nicer to it than its maker.

Sincerely,
Watson Ladd
>
> -Ekr



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

From ynir@checkpoint.com  Mon Dec 30 07:21:06 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E711AE1D5 for ; Mon, 30 Dec 2013 07:21:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.439
X-Spam-Level: 
X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 1qc7C_GcLIFP for ; Mon, 30 Dec 2013 07:21:04 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id F114C1AE1B3 for ; Mon, 30 Dec 2013 07:21:03 -0800 (PST)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rBUFKtCW011002; Mon, 30 Dec 2013 17:20:55 +0200
X-CheckPoint: {52C18AA8-18-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.77]) by IL-EX10.ad.checkpoint.com ([169.254.2.82]) with mapi id 14.03.0123.003; Mon, 30 Dec 2013 17:20:55 +0200
From: Yoav Nir 
To: Alyssa Rowan 
Thread-Topic: [TLS] Remarks on draft-popov-prohibiting-rc4-01
Thread-Index: AQHPBQ/Z648qNZDIh0SFD+5BwyS5c5psXYKAgAAktgCAADd/AA==
Date: Mon, 30 Dec 2013 15:20:54 +0000
Message-ID: <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com>
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> <52C160B4.10103@akr.io>
In-Reply-To: <52C160B4.10103@akr.io>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.24.24]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4D737AFB2E72C84788F0C9A060392531@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [TLS] Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 15:21:06 -0000

On Dec 30, 2013, at 2:01 PM, Alyssa Rowan  wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>=20
> On 30/12/2013 09:50, Yoav Nir wrote:
>> My only issue with this, is that clients and servers have to deal=20
>> with the installed base, and the installed base includes IE6=20
>> running on XP, several older versions of Safari on outdated OSX,=20
>> Firefox 3.6, and thousands of web servers running anything you can
>> think of.
>=20
> Then the installed base *requires* an update: it can no longer connect
> securely, and transport layer _security's_ job is to not be insecure.

Here's the thing. You, me, Yaron and Andrei can tell the world to upgrade i=
n an RFC. The world is not required to listen to us. Browser makers are ver=
y wary of creating browsers that don't connect to what's out there. That's =
why they're willing to downgrade to SSLv3. Server vendors are also wary of =
locking out a bunch of browsers. Two examples of websites for companies tha=
t do care about security:
 - Paypal supports SSLv3, RC4_128_MD5, and 3DES_EDE_CBC_SHA
 - mail.google.com supports SSLv3, RC4_128_MD5, 3DES_EDE_CBC_SHA
 - jpmorgan.com (largest bank in the US) supports SSLv3, RC4_128_SHA, 3DES_=
EDE_CBC_SHA
 - www.nsa.gov (OK, this is a publicity site, but still) supports SSLv3 and=
 EXPORT_WITH_RC4_40_MD5.  OK, maybe not the best example.

And these are the most security-concious of all. What can the rest of us be=
 expected to do?

> Inertia can only go so far, but at some point, we _have_ to rip the
> plaster off. We don't support export-mode anymore, do we?

Mostly not.

> I'd push for removing RC4 support _completely_ - and 3DES-CBC to have
> a security warning and not supported unless you really want to support
> legacy clients. I'd begrudgingly support good old AES-128-CBC w/ SHA
> in TLS v1.0 for legacy (and no MD5 or MD2 at all, either).

OK. Although that would make a fine "which is worse" question for CFRG.

> I'd want EV (green-bar) server requirements to require full compliance
> with draft-sheffer-tls-bcp (or whatever it becomes).

Again, that would give Paypal (as an example) the choice of giving up a bun=
ch of customers or giving up the green bar.

> I'd suggest
> TLSv1.2 AES-GCM as a minimum, and probably also (going forward)
> ChaCha20_Poly1305 support - and downgrade protection, when we can get
> it out there. Also SHA-256 rather than SHA-1.

With current browsers, this means Chrome. Yes, IE had GCM first, but only i=
n a Suite-B ciphersuite. RSA with ECDHE and GCM is Chrome only, and only a =
recent version of Chrome. That implies cutting off some pretty recent brows=
ers and devices.

> Let's remember the broader picture too: XP goes EOL in April, and this
> could well result in a flurry of 0days (deliberately held back until
> after EOL) that will probably not be patched. Possible result: open
> season on internet worms, maybe something along the scale of NIMDA or
> Sapphire. Continuing to support an insecure IE6 even in the face of
> that seems optimistic.

We don't know that this is going to happen. The high-value computers have m=
igrated, and the 30% that still use XP are likely low-value. We may not see=
 attacks at all. XP will not stop working just because Microsoft has decide=
d to stop support. Many users weren't updating their OS anyway.

> Of course, that's only my insignificant viewpoint; and what I'd like
> may be infeasible in the short-term. I'm aware that inertia can be a
> tricky point: probably one of the biggest challenges for TLS.

And that's the point of writing the BCP and this draft.

Yoav


From ekr@rtfm.com  Mon Dec 30 07:51:15 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54071AE235 for ; Mon, 30 Dec 2013 07:51:15 -0800 (PST)
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 BID5jHhIlS_d for ; Mon, 30 Dec 2013 07:51:14 -0800 (PST)
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 079361AE13C for ; Mon, 30 Dec 2013 07:51:13 -0800 (PST)
Received: by mail-wg0-f47.google.com with SMTP id n12so10106951wgh.2 for ; Mon, 30 Dec 2013 07:51:07 -0800 (PST)
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:content-transfer-encoding; bh=OgbAdgYA8AWm7S+lEhOl0tx6ZjPLlhOfzI5UEli9jWA=; b=lndo6RwJd7pdSbnJvEq/xRHMPLu+CxgC+TnkhaSYYT4pBfRcBOnstdwMFlAdYuc2YY 7PEUKHJRBVV6OGMbF4Sd8tgtaQH3GzbDe6CMfoJSA3zeLgn52j45e4IrNJTX6SQm/4/J HqAoRzAN3epadiuAWXt3b1GNLd+IJP96NLzXoWoGrhlOVKLRiNiQy1CgtXjlVDWE146k WPtJpq+E7Ejv/+pNBzdtPjsF2ymZ87Gcpl9rh5FhwRFbbViSzSfZ4ZczwIRzGF/zXbPb Mo3nKFPaMEMtA5bc/WnEhuoyK7fFS1S8EGyiSMLuQNmAArMW7L0lirwqIkkhB8AopXaD KU6Q==
X-Gm-Message-State: ALoCoQmeNVgsgsaHzQCy+sZFjHhIpKXKvVpFrQ6SrX/W+Z7PXEWVFw+Bp8zYLbbNK8vdxEIiJpe0
X-Received: by 10.194.175.133 with SMTP id ca5mr42221323wjc.19.1388418667500;  Mon, 30 Dec 2013 07:51:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Mon, 30 Dec 2013 07:50:27 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: 
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com>   
From: Eric Rescorla 
Date: Mon, 30 Dec 2013 07:50:27 -0800
Message-ID: 
To: Watson Ladd 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 15:51:15 -0000

On Mon, Dec 30, 2013 at 7:20 AM, Watson Ladd  wrote:
> On Mon, Dec 30, 2013 at 8:59 AM, Eric Rescorla  wrote:
>> On Mon, Dec 30, 2013 at 4:48 AM, Watson Ladd  wro=
te:
>>> On Mon, Dec 30, 2013 at 4:50 AM, Yoav Nir  wrote:
>>>> My only issue with this, is that clients and servers have to deal with=
 the installed base, and the installed base includes IE6 running on XP, sev=
eral older versions of Safari on outdated OSX, Firefox 3.6, and thousands o=
f web servers running anything you can think of.
>>>>
>>>> So if you take away RC4, you still have to support CBC ciphersuites fo=
r 3DES (maybe AES would work most of the time=85) without the modification =
being discussed in another thread.
>>>>
>>>> So given the choice between RC4 and 3DES-CBC without P-E-M and without=
 fancy 1-byte-record BEAST mitigation, which would you prefer?
>>>
>>> 3DES-CBC. BEAST requires the ability to inject data on record
>>> boundaries, and 3DES attacks are chosen-plaintext. Given that IE6
>>> doesn't
>>> support the new features that permit such an injection, it's not my
>>> favorite thing in the world, but better than RC4.
>>
>> Not to disagree with the main point that we should be more interested
>> in removing RC4, but what Web browser features do you believe are
>> required to mount attacks on CBC cipher suites?
>
> You need to be able to inject chosen-plaintext with a high degree of
> control into an existing TLS connection.

Not only an existing TLS connection but one that contains data
that the attacker would otherwise not be able to access, like
a cookie.


> The BEAST demo used Java, but Websockets was also vulnerable.

To the best of my knowledge, while a draft version of WebSockets
(WebSockets-76 IIRC) was vulnerable WebSockets as standardized
in RFC 6455 was not vulnerable due to the masking feature
(http://tools.ietf.org/html/rfc6455#section-5.3), though this
feature was introduced for other reasons (see [0]).

-Ekr

[0] http://w2spconf.com/2011/papers/websocket.pdf

From tom@ritter.vg  Mon Dec 30 07:54:07 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601801AE13C for ; Mon, 30 Dec 2013 07:54:07 -0800 (PST)
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, 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 LfKoD1bqrDMp for ; Mon, 30 Dec 2013 07:54:06 -0800 (PST)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2971ADF4F for ; Mon, 30 Dec 2013 07:54:06 -0800 (PST)
Received: by mail-pd0-f169.google.com with SMTP id v10so11424840pde.14 for ; Mon, 30 Dec 2013 07:54:00 -0800 (PST)
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=dDdp+XuWV5kFKvWE1tQOkWLeLAZqJnGSxu0GPNUsYfw=; b=LC1mKyqvb9Rgr87GqO2AcWTWDb6n9ItWKnIjHi6Enx+mgZZXbyQbqfFJ1LROuFlm3U xhUXtKKis0eBHnHLXKVle7jt47f1HE88nzMu/IXJV+mYE1DnJnFF5GmDDvMdBmAmbi9m 143soX+dRDfJk9hKC+eLAsWPg1d8lxF8qrBww=
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=dDdp+XuWV5kFKvWE1tQOkWLeLAZqJnGSxu0GPNUsYfw=; b=dRN25uxQWn/xLvbiHLG9QPzQcctLIoZRCfL4IpLarG2MVi0u7oyARjqWOPO1DgyQIw +ScJp464hkAYMKwmHO3LMrbPJgRKLJlYazVZJMyftgLuNESKyXEC7i1tgUsSIlXU7A+G zAaiJx96Fj1jXsRtnpJtN246Ctu2pEftN0+owIKvzEGTh5ptt0f4PIM8LxOwqY17TkYZ b0ERK63kW47VBYg4Pk257NGohvWISaO7+W0vlBwQjYPzN2KRra10TDmr9gVBM0e1eH8c cHdCUXdBAny7KPHYn+WMUi8rQ+6QiMA5ZlhGkQ0E30yZCISJpVw1I+n7N+5mEXriiwSW a3nw==
X-Gm-Message-State: ALoCoQnyIkMpeRCg861zJaGsV5ubAMyNJLm1+Y1ocqyFS7F9iHtUDXv2whxaTcs6mQmiZ0VumJv2
X-Received: by 10.68.189.197 with SMTP id gk5mr69154996pbc.37.1388418840655; Mon, 30 Dec 2013 07:54:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.169.193 with HTTP; Mon, 30 Dec 2013 07:53:40 -0800 (PST)
In-Reply-To: 
References:  
From: Tom Ritter 
Date: Mon, 30 Dec 2013 10:53:40 -0500
Message-ID: 
To: Yoav Nir 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fixing CBC Mode II: Indicating new GenericBlockCipher construction
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 15:54:07 -0000

On 30 December 2013 06:12, Yoav Nir  wrote:
> If the client persists in sending the SCSV, the middleware may miss it and
> forward the ClientHello to the server. In that case, the server will reply with
> an extension, that the middleware will drop.

Are you certain about this? I haven't seen anyone talk about
middleware intolerant to a _server's_ extensions, just a client's. I
just tested my server (Apache/OpenSSL) with a SSL v3 handshake. I sent
no extensions, I received a response with the renegotiation extension.
If middleware dropped server hellos with extensions, I believe we'd
see a lot more broken internet, as servers will not downgrade their
options. Right?

-tom

From tom@ritter.vg  Mon Dec 30 07:55:12 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6AA41AE4F8 for ; Mon, 30 Dec 2013 07:55:12 -0800 (PST)
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, 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 8wYMx_ZXIlGN for ; Mon, 30 Dec 2013 07:55:10 -0800 (PST)
Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id D5ADA1AE4F5 for ; Mon, 30 Dec 2013 07:55:10 -0800 (PST)
Received: by mail-pd0-f180.google.com with SMTP id q10so11459221pdj.39 for ; Mon, 30 Dec 2013 07:55:05 -0800 (PST)
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=V1BKMKhMDNUyx3NJt4bQUvZlCk5X37d8qdNEftjLfPE=; b=APTOOKaC+5W9hiC4vVGfy+QdguG6d1nDItoNo+xKryqEpxbwdufbDf+8wVVSjJ2ajr Vc8WTWbZzRF0Y7PCHP5V91G9kFHAEolCAve1ATtS4p/hs2URvgpgs6rwcpRE/u+STa4I L5yQ78dalvJHwQZfwSNtdEKp7WLgKC0760qFQ=
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=V1BKMKhMDNUyx3NJt4bQUvZlCk5X37d8qdNEftjLfPE=; b=L8ggvCrVlCWTeKMn59eNFOKyM56QydNX97eSSkY/unk67CeW/mYZ6ujNhBpnk1pZl+ 867UEYrbgpnuKNKX7tvKycN5KHCtKqfahDzLv2Sb6mgZGCfeTvxPGwTBa8l7ownnjwlG BrHPb2zTFxfT7t98DW3difa9d2SewDnjfY2OphE9PZsDae/GSABqubUkSqjKdgDquqbI H65cHvAK+NK5ucvQEWyMtgtMMCz3jx5yinba20OyUCKzMVsA3zzXb5n1B9jVRqweNte6 af9SeYXJ5JEfshP0i+yhH26McUAt+mRbTt6uTkUvQ1MF5iYfVBDgyMioqVxkxV/qU+zw NWRw==
X-Gm-Message-State: ALoCoQnGKYG283s6c0yMiIdHhtJn/lP3VcMjG/oDgg+i+f6s2yZDnCeufqzQ+peHm2W0+VnX2KIR
X-Received: by 10.66.142.132 with SMTP id rw4mr70537625pab.6.1388418905153; Mon, 30 Dec 2013 07:55:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.169.193 with HTTP; Mon, 30 Dec 2013 07:54:45 -0800 (PST)
In-Reply-To: 
References: 
From: Tom Ritter 
Date: Mon, 30 Dec 2013 10:54:45 -0500
Message-ID: 
To: Eric Rescorla 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fixing CBC Mode I: GenericBlockCipher construction
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 15:55:13 -0000

On 29 December 2013 18:15, Eric Rescorla  wrote:
> We have seen two major proposals for fixing the GenericBlockCipher
> construction:
>
> - Encrypt-then-MAC
> - Pad-MAC-Encrypt

I favor Encrypt-then-MAC.

-tom

From ekr@rtfm.com  Mon Dec 30 08:12:39 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E7D1AE4F5 for ; Mon, 30 Dec 2013 08:12:39 -0800 (PST)
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 2NXHMSKcW02u for ; Mon, 30 Dec 2013 08:12:37 -0800 (PST)
Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3C41AE26E for ; Mon, 30 Dec 2013 08:12:37 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id m15so10087512wgh.1 for ; Mon, 30 Dec 2013 08:12:30 -0800 (PST)
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=I7O4Uch0DXHsq4VtiQHNXCbktv+4j0g/Pp+RjhBKLAw=; b=LxpyaM0159m1Sg7pPGEz7ANfWqLOyR8W3zPD/W84wPbVr6ZK2Ml4i6sIftyL+tuYJm CrG3s60x5TM970t7wrm3/LSackV60f52kBY3lXtrmZ3nNRZcEE3VqXuauvR7KJXWMr78 DY2WSw/P+WXlGFwnpuVxH+wueCWFXnzRbxFJ23u8P4Mu/YvJKxPkG/jl/LqvU9xCv1Ap b+22DruzMOTYk3rm8ULl3AoRMlv6b8IJJJI8KhX2X+mjojfqHEKOLYHq3jOssY91khcp FuK6chvmUpVLh5cfF9cinK5DoVM5ZeD6ZwYsZEvEbrbE2ZI3tI7SXo80RDoP8XOU+h26 8f4w==
X-Gm-Message-State: ALoCoQn/CGtxur2muggtM3rz5a2E92LJmXX9hDId4O+/0o2GVcidgsrQwbRKDuq36MvVERQ732vG
X-Received: by 10.180.14.231 with SMTP id s7mr31986200wic.1.1388419950786; Mon, 30 Dec 2013 08:12:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Mon, 30 Dec 2013 08:11:49 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com>
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> <52C160B4.10103@akr.io> <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com>
From: Eric Rescorla 
Date: Mon, 30 Dec 2013 08:11:49 -0800
Message-ID: 
To: Yoav Nir 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" 
Subject: Re: [TLS] Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 16:12:39 -0000

On Mon, Dec 30, 2013 at 7:20 AM, Yoav Nir  wrote:
>
> On Dec 30, 2013, at 2:01 PM, Alyssa Rowan  wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> On 30/12/2013 09:50, Yoav Nir wrote:
>>> My only issue with this, is that clients and servers have to deal
>>> with the installed base, and the installed base includes IE6
>>> running on XP, several older versions of Safari on outdated OSX,
>>> Firefox 3.6, and thousands of web servers running anything you can
>>> think of.
>>
>> Then the installed base *requires* an update: it can no longer connect
>> securely, and transport layer _security's_ job is to not be insecure.
>
> Here's the thing. You, me, Yaron and Andrei can tell the world to
> upgrade in an RFC. The world is not required to listen to us. Browser
> makers are very wary of creating browsers that don't connect to
> what's out there. That's why they're willing to downgrade to
> SSLv3. Server vendors are also wary of locking out a bunch of
> browsers.

To elaborate on this point a bit, the critical factor here is clients
and servers which support *only* RC4, since that's what causes bustage.
Historically, client vendors have resisted any change which breaks
more than a small fraction of connections (and presumably server
operators feel the same way).

As a reality check, maybe we could get AGL, bsmith, Andrei, Wan-Teh
etc. to weigh in on how small the RC4-only population would have to be
before they are willing to turn off RC4 support in their products.

-Ekr

P.S. Ignoring general equilibrium effects simply having clients and servers
configured so that any pair which have a common cipher X better than
RC4 select X instead is still pretty good (assuming that the negotiation
is secured, and we have anti-rollback if necessary), since the impact
would be that X is selected where possible and RC4 where necessary.
Unless I misunderstand, RC4 is still superior to plaintext against the
current best results.

From ynir@checkpoint.com  Mon Dec 30 08:14:25 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33A01AE532 for ; Mon, 30 Dec 2013 08:14:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.439
X-Spam-Level: 
X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 o5yMXSO7FH0o for ; Mon, 30 Dec 2013 08:14:22 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 653861AE52E for ; Mon, 30 Dec 2013 08:14:22 -0800 (PST)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rBUGEF87028214; Mon, 30 Dec 2013 18:14:15 +0200
X-CheckPoint: {52C19728-26-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.77]) by IL-EX10.ad.checkpoint.com ([169.254.2.82]) with mapi id 14.03.0123.003; Mon, 30 Dec 2013 18:14:15 +0200
From: Yoav Nir 
To: Tom Ritter 
Thread-Topic: [TLS] Fixing CBC Mode II: Indicating new GenericBlockCipher construction
Thread-Index: AQHPBXdk9cHm6/pzYE6BVW3ioMHf5Jpsx9yA
Date: Mon, 30 Dec 2013 16:14:14 +0000
Message-ID: <77CBD788-D4B5-4C55-8C66-465E81EC3B65@checkpoint.com>
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.24.24]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fixing CBC Mode II: Indicating new GenericBlockCipher construction
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 16:14:25 -0000

On Dec 30, 2013, at 5:53 PM, Tom Ritter  wrote:

> On 30 December 2013 06:12, Yoav Nir  wrote:
>> If the client persists in sending the SCSV, the middleware may miss it a=
nd
>> forward the ClientHello to the server. In that case, the server will rep=
ly with
>> an extension, that the middleware will drop.
>=20
> Are you certain about this? I haven't seen anyone talk about
> middleware intolerant to a _server's_ extensions, just a client's. I
> just tested my server (Apache/OpenSSL) with a SSL v3 handshake. I sent
> no extensions, I received a response with the renegotiation extension.
> If middleware dropped server hellos with extensions, I believe we'd
> see a lot more broken internet, as servers will not downgrade their
> options. Right?

Hmm, hadn't thought of that. Come to think of it, RI did introduce the (app=
arently) unsolicited serverHello extension. I'm wondering if clients downgr=
ade to SSLv3 without SCSV if SSLv3 with SCSV fails. Probably not. Extension=
-intolerant proxies are pretty rare, but it seemed to me that if they were =
intolerant of users sending extensions, they would be equally intolerant of=
 servers sending them.=20

So maybe SCSV does have some value here.

Yoav=

From akr@akr.io  Mon Dec 30 10:44:33 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7C31AE538; Mon, 30 Dec 2013 10:44:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level: 
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 waVri6aLbgny; Mon, 30 Dec 2013 10:44:30 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id D5D551AE535; Mon, 30 Dec 2013 10:44:29 -0800 (PST)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id 9B3096094C; Mon, 30 Dec 2013 18:44:22 +0000 (GMT)
Message-ID: <52C1BEF1.4030406@akr.io>
Date: Mon, 30 Dec 2013 18:44:01 +0000
From: Alyssa Rowan 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tls@ietf.org, uta@ietf.org
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> <52C160B4.10103@akr.io> <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com>
In-Reply-To: <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 18:44:33 -0000

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

(Hi to the UTA list. Crossposting because of the discussion pertaining
 to a TLS BCP.)

On 30/12/2013 15:20, Yoav Nir wrote:

> Here's the thing. You, me, Yaron and Andrei can tell the world to 
> upgrade in an RFC. The world is not required to listen to us.

Alas, so very true. I'm well aware the gulf between what we'd really
like and what we can actually get is hard to bridge.

> - mail.google.com supports SSLv3, RC4_128_MD5, 3DES_EDE_CBC_SHA

No doubt a very considered example. I'm sure agl (et al) could
enlighten us as to why the presence and ordering of each suite;
probably targeting individual demographics.


On 30/12/2013 16:11, Eric Rescorla wrote:

> As a reality check, maybe we could get AGL, bsmith, Andrei, Wan-Teh
> etc. to weigh in on how small the RC4-only population would have to
> be before they are willing to turn off RC4 support in their 
> products.

That would be demographically enlightening. (If a little depressing.)


Allow me to distil my thoughts:

• We want to avoid RC4 whenever possible, because it is insecure
  - How insecure? From what we know, and what we guess:
    · Nation State Adversary: Probable complete failure
    · Public knowledge: Suspected imminent failure
    · Anything's better than plaintext - even RC4
    · But so are export ciphers, and we rightly don't use those anymore!
  - Today's NSA attack may be tomorrow's public attack
    · Tomorrow's attacks applicable in retrospect to today's traffic!
    · Which is why NSA save everything, even if they can't break it now
  - Conclusion: Every time we negotiate RC4, it's a bad outcome
    · We should avoid it whenever it is possible to do so
    · But it may not be possible for some to avoid it

• Is TLS 1.0 AES-128-CBC preferable after all where possible?
  - Agreed, we should definitely ask CFRG for input
  - I personally suspect yes:
    · BEAST & Lucky13: active, noisy, and at least have some mitigation
    · But an RC4 break might be passive, and historically applicable
    · That's suggestive to me that RC4 is more dangerous than AES-CBC

• Some bad clients, and some bad servers, only support RC4
  - There is no secure way left to connect to them
  - They're doomed: we can only do the best we can & encourage upgrade

• Do we want to hard-fail on insecure connections?
  - Depends; no easy answer
  - Our job is to not be insecure; implementations have other priorities
  - If new browser can't connect to a site, user blames the new browser
  - If customers can't connect to new server, new server gets the blame
  - Conclusion: We need a transition period, with RC4 as "last resort"?

• How can we make sure it's a last resort?
  - Downgrade protection { draft-bmoeller-tls-downgrade-scsv-01 }
    · We _really_ need this!
    · Else attacker can trick us back into SSLv3 and/or RC4, or worse?
  - Remove known-insecure ciphersuites from TLS 1.3?
    · Revisit later.

• Should we warn if RC4 is negotiated as a last-resort?
  - Yes, I think we should
    · Clients: similar 'server insecure' warning, like RSA-512 / MD5?
    · Servers: likely want to support legacy clients for a while
    · But might want to loudly warn/encourage them to upgrade _now_

• Practical replacements we can roll out without ruffling feathers:
  - TLS 1.2: ChaCha20_Poly1305 { draft-agl-tls-chacha20poly1305-01 }
    · Faster than RC4
    · 2^256 conf; 2^90 auth, ish
    · Better than AES (side channel avoidance; apparently stronger)
    · Requires TLS 1.2 because AEAD
  - TLS 1.2: AES-128-GCM
    · Already in TLS 1.2 (and NIST Suite B); deployment ongoing
    · Complicated to avoid side-channels in software implementations
    · But fast & good hardware support available on some platforms
    · Requires TLS 1.2 because AEAD
  - TLS 1.1/1.0: ChaCha20_SHA { draft-mavrogiannopoulos-chacha20-tls }
    · Worse authenticator than ChaCha20_Poly1305
    · But backwards-compatible with TLS 1.0 & TLS 1.1
    · And much better than any other choice available there
    · Good third choice; second, if AES-GCM not hardware accelerated
    · Not loving having to use HMAC_SHA1 but TLS 1.0/1 is stuck with it
    · When would this be useful? TLS 1.2-intolerant middleware? (Which?)

• How can we encourage adoption?
  - TLS BCP
    · Being handled by (very new) UTA list
    · Likely delay as a result; not ideal, but forward-thinking
    · Try to get some momentum? (Thus, crossposted for discussion.)
  - Once finished: point standard/compliance orgs to TLS BCP?
    · PCI DSS might provide some incentive, even to geological-time
      inertia of financial orgs? Maybe?
    · Anyone else?
  - Any other ideas?

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

iQIcBAEBCgAGBQJSwb7xAAoJEOyEjtkWi2t6iLQQALAf7MUYgfKrQGCEEUeeIHGT
f9L3SXHJQiCUK5aHYk8pPfDYfat0l24+SHnvPbOuOnvflxr3BpFl5dOdcaY6n9LS
VDnNOYN662VE9REEbkaCpZpzxlwc8rjwHGj+oLg3V8K7p3KeiFRULv4YcpHVD2A9
99YfC5SCTif5vrXfqJUbuPTIg51xnEu9wJ8rg+qYJopYvXCT6THv4G34JgSnuJx/
KG5MhmM7pdxTSEpQPd3QQYlE4mDvGIakRFVY0xZOaodembAACCKFDPpBDEheCgcL
vXhVy2AXIiFxH4KsiGv58yOqW1ixRcOMoITX9jp3tegPHm8JWcrvH5dwIC/kRbOn
XrrYL4RGlGvZqcG0imd2jKcsix0cxqx5TwkklN481q7jURyiMbP1O+Wu5MXsrXNQ
ZzdGmv/b8oY4gJfpFRFH+WdLWJXslNpDAxGrnxNEJUgtiytPM0us1KCGbRB5vN5j
PHpjZYZ4tYD+L/JPg1RTDlVt9VsMl2zaSZmxXCJmWb3LlGEPm+1z+LDiCykhKQ9k
OD0C3Hq7YgZFO2sOdCJXGyupmiyRhaAowxnWz1uzpmpyoiEXs2frYM1uDc3f9IQ1
xn1rYOOmLGHnQmwwEnJ5oufjZ2aLCvzmC6W+KdYOn5GP4J/aKV1iZ6BKTExZomL0
KE01uRxIEDxrifCM8MI1
=HrOH
-----END PGP SIGNATURE-----

From mpg@polarssl.org  Mon Dec 30 11:59:22 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1351B1AE547; Mon, 30 Dec 2013 11:59:22 -0800 (PST)
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 QEN9GfwYES6h; Mon, 30 Dec 2013 11:59:20 -0800 (PST)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8681AE1DE; Mon, 30 Dec 2013 11:59:20 -0800 (PST)
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=0gH2JWHsdBAgwS9nZvER77NxQG6cEJ1tdpZVdkL9Ies=;  b=onWEqEMzrIAxDmGbMqKmLAWUZRQjfB0Z56/FwPUmV9LjCjVB5MshuRahzaaTG/e/lTauqmioopUiftpZ7C43RfY0O44wYdDOjZcnPqCsTIG/X49fjdMsM4+2a587/uNp2wx8dj9BYmPNd8y3qV5umozOggh6E563hArR9z/eHn4=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VxisW-0006kL-SI; Mon, 30 Dec 2013 20:51:57 +0100
Message-ID: <52C1D091.9040806@polarssl.org>
Date: Mon, 30 Dec 2013 20:59:13 +0100
From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1
MIME-Version: 1.0
To: Alyssa Rowan , tls@ietf.org, uta@ietf.org
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> <52C160B4.10103@akr.io> <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com> <52C1BEF1.4030406@akr.io>
In-Reply-To: <52C1BEF1.4030406@akr.io>
Content-Type: text/plain; charset=UTF-8
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)
Subject: Re: [TLS] Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 19:59:22 -0000

On 30/12/2013 19:44, Alyssa Rowan wrote:
> • Is TLS 1.0 AES-128-CBC preferable after all where possible?
>   - Agreed, we should definitely ask CFRG for input
>   - I personally suspect yes:
>     · BEAST & Lucky13: active, noisy, and at least have some mitigation
>     · But an RC4 break might be passive, and historically applicable
>     · That's suggestive to me that RC4 is more dangerous than AES-CBC
> 
I tend to agree: being vulnerable to passive attacks is much worse than being
vulnerable to active attacks. Besides the fact than passive attacks can be done
more pervasively, they also can be done in the future on material recorded now
(as you note earlier).

>   - If new browser can't connect to a site, user blames the new browser
> [...]
> • Should we warn if RC4 is negotiated as a last-resort?
>   - Yes, I think we should

I really like the idea of using RC4 as a last-resort but with a loud warning. It
shifts the blame from the new browser to the "old" server.

I'm curious to hear opinions of browser people on this idea.

>     · Clients: similar 'server insecure' warning, like RSA-512 / MD5?
>     · Servers: likely want to support legacy clients for a while
>     · But might want to loudly warn/encourage them to upgrade _now_
> 
I think there are two kinds of servers here:

1. The servers which can negotiate something better than RC4, but will also
negotiate RC4 if the client doesn't offer anything better. It solves the "likely
want to support legacy clients for a while" issue for server admin, without
hurting security too much (actually not at all if/when we have downgrade
protection).

2. The servers which can negotiate something better but actually prefer RC4. For
example, right now google.fr seems to prefer RC4 over any other cipher Firefox
26 or Chromium 30 offer, which include AES-CBC (but not AES-GCM).
If we agree that RC4 is more dangerous than AES-CBC, then these servers are
actively hurting security.

Since I know there are a lot of knowledgeable people who care about security at
google, I might be missing something here.

Manuel.


From mpg@polarssl.org  Mon Dec 30 12:21:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885821AE30E for ; Mon, 30 Dec 2013 12:21:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.794
X-Spam-Level: *
X-Spam-Status: No, score=1.794 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 ZdSq_R_cjoUX for ; Mon, 30 Dec 2013 12:21:34 -0800 (PST)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id BF6ED1AE137 for ; Mon, 30 Dec 2013 12:21:34 -0800 (PST)
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=ILMpAicsxpCA9HBqXmq81Iobdg4n9zBS/5uo/VbO7yw=;  b=Uux49VMAhPQiyu421Vko7JkPAY4aKQT4coFDyl8hGAD/BKih4fWjrbYPVavOCUdxNZKmJnfUiNQq38fVGx4dfdwns5mVYU8icHFn1vrs+NdjemT9BydCtCImmiSIJZ1Ks28Z2XZXE5uXwpFyhQzWy3PqR2uH3Q4EF65jG1Qi7vA=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VxjE3-0006oS-MZ for tls@ietf.org; Mon, 30 Dec 2013 21:14:12 +0100
Message-ID: <52C1D5C8.7060702@polarssl.org>
Date: Mon, 30 Dec 2013 21:21:28 +0100
From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1
MIME-Version: 1.0
To: tls@ietf.org
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> <52C160B4.10103@akr.io> <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com> <52C1BEF1.4030406@akr.io>
In-Reply-To: <52C1BEF1.4030406@akr.io>
Content-Type: text/plain; charset=UTF-8
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)
Subject: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 20:21:35 -0000

[forking thread for discussion on a side point]

On 30/12/2013 19:44, Alyssa Rowan wrote:
>   - TLS 1.1/1.0: ChaCha20_SHA { draft-mavrogiannopoulos-chacha20-tls }
> [...]
>     · Not loving having to use HMAC_SHA1 but TLS 1.0/1 is stuck with it
> 
Are we really stuck with SHA1 (as opposed to SHA-256 or SHA-384) for HMAC on TLS
1.0 and 1.1?

At least three RFCs (5487, 5489 and 6367) that define ciphersuites with
HMAC-SHA2 explicitly allow them to be used with TLS < 1.2. Quoting from RFC 6367
(section 3.3) for example:

   The hash algorithms and pseudorandom function (PRF) algorithms for
   TLS 1.2 [8] SHALL be as follows:

   a.  The cipher suites ending with _SHA256 use HMAC-SHA-256 [1] as the
       MAC algorithm.  The PRF is the TLS PRF [8] with SHA-256 [13] as
       the hash function.

   b.  The cipher suites ending with _SHA384 use HMAC-SHA-384 [1] as the
       MAC algorithm.  The PRF is the TLS PRF [8] with SHA-384 [13] as
       the hash function.

   When used with TLS versions prior to 1.2 (TLS 1.0 [2] and TLS 1.1
   [6]), the PRF is calculated as specified in the appropriate version
   of the TLS specification.

On the other hand, at least one other RFC that defines SHA-2 and ciphersuites
explicitly prohibits their use with TLS < 1.2. Quoting from RFC 5932 3.3.3:

   The cipher suites ending with _SHA256 use HMAC-SHA-256 as the MAC
   algorithm.  The PRF is the TLS PRF [RFC5246] with SHA-256 as the hash
   function.  These cipher suites MUST NOT be negotiated by TLS 1.1 or
   earlier versions.  Clients MUST NOT offer these cipher suites if they
   do not offer TLS 1.2 or later.  Servers that select an earlier
   version of TLS MUST NOT select one of these cipher suites.

At least one other RFC (5289) defines SHA-2 suites without any hint about
whether they can be used with TLS < 1.2 or not. (We count even count RFC 5246 in
this category.)

It seems to me that allowing HMAC-SHA256/384 with TLS 1.0 and 1.1 should not be
a problem for implementers. At least, I didn't see a problem when lowering the
version requirements for the ciphersuites from RFCs that allow them with < 1.2
in PolarSSL, but on the other hand I couldn't test interop since I was unable to
find another implementation that uses those SHA-2 suites with TLS < 1.2...

What is the group's opinion on using HMAC-SHA256/384 suites with TLS < 1.2?

Manuel.

From akr@akr.io  Mon Dec 30 13:52:50 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533ED1AE308 for ; Mon, 30 Dec 2013 13:52:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level: 
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 BrU-A1OFeWYR for ; Mon, 30 Dec 2013 13:52:47 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id B134B1AE309 for ; Mon, 30 Dec 2013 13:52:46 -0800 (PST)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id AF9C56041F for ; Mon, 30 Dec 2013 21:52:39 +0000 (GMT)
Message-ID: <52C1EB13.3050909@akr.io>
Date: Mon, 30 Dec 2013 21:52:19 +0000
From: Alyssa Rowan 
MIME-Version: 1.0
To: tls@ietf.org
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> <52C160B4.10103@akr.io> <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com> <52C1BEF1.4030406@akr.io> <52C1D5C8.7060702@polarssl.org>
In-Reply-To: <52C1D5C8.7060702@polarssl.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 21:52:50 -0000

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

On 30/12/2013 20:21, Manuel Pégourié-Gonnard wrote:

> What is the group's opinion on using HMAC-SHA256/384 suites with
> TLS < 1.2?

Why stop there? We had the SHA-3 competition last year: if we intend
to replace SHA-1, why use SHA-2?

The competition yielded five excellent replacements, some of which are
faster than SHA-2¹, none of which were designed by the NSA², and none
of which have length-extension attacks³: Keccak (selected by NIST as
SHA-3), Skein, BLAKE, JH and Grøstl.

Perhaps we should make our own determination and/or take advice from
CFRG as to which of these might be suitable for future use in the
alternative?

To me, the leading three from the SHA-3 finalists are:

• Keccak (SHA-3):
  - Poorish software performance: roughly SHA-2 speed or slower.
  - Not as well analysed as some other SHA-3 candidates.
  - NIST-approved. (Is this a positive or negative now? )
  - Possible _future_ good hardware performance, due to being selected
    as SHA-3: not likely to be relevant for years yet, however.
  - NIST didn't eventually make any midnight-hour changes: trust issues.
• Skein:
  - 72 round fast ARX tweakable block cipher core with a smooth finish.
  - Excellent software performance - roughly 2× SHA-2 & SHA-3 speed.
  - Very well-analysed.
• BLAKE:
  - Based on a tweaked ChaCha14/ChaCha16, lengthways and diagonally.
  - Excellent software performance, competitive w/ Skein (just loses)
  - Very well-analysed.

JH or Grøstl are slower so not as attractive.

While Skein was my favoured of the bunch in general, I note the
delicious symmetry of BLAKE being based upon a slightly modified
version of the stream cipher we're planning to use.

I'd therefore tentatively suggest ChaCha20_HMAC-BLAKE256 as a TLS 1.0/
1.1 alternative to ChaCha20_Poly1305, if it's thought appropriate
(CFRG?), and I'd suggest that over and above HMAC-SHA256.

And software performance right now I feel is more relevant for the
ChaCha20 ciphersuites, because those are especially good for platforms
where AES & GCM hardware acceleration isn't available, and it's hard
to suppose of a future platform that would accelerate SHA-3 but not
AES or GCM.

Whereas for TLS 1.3, perhaps I could see SHA-3 as a NIST-selected
alternative alongside Skein or BLAKE, for possible future agility.

Thoughts?

___
1. Current performance: 
2. I don't think the NSA intentionally weakened SHA-2. It's OK,
   length-extension aside. But we can have more independent confidence
   in something they didn't design.
3. Which resulted in NIST calling the SHA-3 competition.

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

iQIcBAEBCgAGBQJSwesSAAoJEOyEjtkWi2t6uugP/2wQLTWKCfoubEmYl1D/wVEv
BKo38oNJHQoKmJOgqUmoRYp4BDzeVcNDsllnESIJi5uc3O/tkIoTCgbbpiAO0tW3
MH2c+Hg3Qf+BjjbovMDf45ekFkz3+3onR1TI2Vh6tMP2fybbAiBZXZ2fWpdk0d5H
wArhOV4nBXWDPnjCNJpvstOwaXmR3cgkE7tNwMUXXJ7Dr4mm93kYpaM+ztAQ/DZj
VHA5AfX4JRXajK3S5qkmJdZokMWDU7VPkt58AcyCudRCZY/ROFuqRe2H3E8ryG5J
VXYqGLYxUrsagFCahYBwYbpGXtiHs6Jveb+MAdsB7ZOmGpPlkKijzGQs7CGOcnFb
35fH+steCMskZbaS5pq0+47TdFkIIvWCobiPso8s4ohP1k1zF78dki9/cWMQ8U4W
DpxWKrE0WDYDogpLXtmomoF3W5CFYNXBIMHBrcyP1nLthqSGDwL8FHGvOlQ/1gOW
p51CeNrOOVGK11dX90A/u5zRwXgn8PjoiT+tJ/DjznCuTcLphKeNU1SdNg5jxYeZ
98Wqp5QBs9U+Cdfqoncp2fYOiLt0RcVCbb1uO5ps2dyPkTNSSswhF5SSM82OK4N3
/ZqF1v7ZWp2YJ/3tRH87pXXztenTAovITQsbT6Fxswx2dKmHMUHmOSXCfFyCl+As
GT3gIhkHm2wMsanNAoZE
=w3Z3
-----END PGP SIGNATURE-----

From watsonbladd@gmail.com  Mon Dec 30 14:27:19 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2141AE320; Mon, 30 Dec 2013 14:27:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 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_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 W0WHU0lFGZKo; Mon, 30 Dec 2013 14:27:18 -0800 (PST)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id C44E61AE311; Mon, 30 Dec 2013 14:27:17 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id z12so10379775wgg.15 for ; Mon, 30 Dec 2013 14:27:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zJha3QNTBSrskug6fra/FW0FL3objHhQ2qEmeXYQDoQ=; b=heIY6Nru4AVInBS2a8GOiv8Gp4GIksh4ILf5CdLZiATMbyzFMbuFeAUJiWGNXlQlJZ jC3XVi29odT0Wh4s0Ocj6dFyYTjS/3d22hxZJ8XF5D+1Agxd6/nB4oDxF29cCWIp7mSk GPH4vbdsrHpIWzPuxgP6FUggE/lxQ/cEHMEculBl9Vmn/U5pCP/R+rXJW+g12nJomVg6 +Rq3Htioh3ikcXv28XVRK+7P/1hBFPZy53y2VQK0JPVbsMxCwYBMHTCwaw5nOFlTkM+a dnR3bDzdTteOE1FzY2arEuNll5BImssgzTE8ZdUISE79gZ9Ga+jbqNpig0GrH6ya2OkH zpYg==
MIME-Version: 1.0
X-Received: by 10.180.94.164 with SMTP id dd4mr46020645wib.20.1388442431344; Mon, 30 Dec 2013 14:27:11 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 30 Dec 2013 14:27:11 -0800 (PST)
In-Reply-To: <52C1D091.9040806@polarssl.org>
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> <52C160B4.10103@akr.io> <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com> <52C1BEF1.4030406@akr.io> <52C1D091.9040806@polarssl.org>
Date: Mon, 30 Dec 2013 17:27:11 -0500
Message-ID: 
From: Watson Ladd 
To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: uta@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 22:27:19 -0000

On Mon, Dec 30, 2013 at 2:59 PM, Manuel P=C3=A9gouri=C3=A9-Gonnard
 wrote:
> On 30/12/2013 19:44, Alyssa Rowan wrote:
>> =E2=80=A2 Is TLS 1.0 AES-128-CBC preferable after all where possible?
>>   - Agreed, we should definitely ask CFRG for input

> I think there are two kinds of servers here:
>
> 1. The servers which can negotiate something better than RC4, but will al=
so
> negotiate RC4 if the client doesn't offer anything better. It solves the =
"likely
> want to support legacy clients for a while" issue for server admin, witho=
ut
> hurting security too much (actually not at all if/when we have downgrade
> protection).
>
> 2. The servers which can negotiate something better but actually prefer R=
C4. For
> example, right now google.fr seems to prefer RC4 over any other cipher Fi=
refox
> 26 or Chromium 30 offer, which include AES-CBC (but not AES-GCM).
> If we agree that RC4 is more dangerous than AES-CBC, then these servers a=
re
> actively hurting security.

I think it is important to distinguish between configuration changes
(hopefully easy)
and upgrades (not so easy). If it was possible to distinguish between
1/n-1 record
splitters and not, we would be able to use RC4 only when necessary.
But it isn't possible,
so either you upgrade to something reasonable like AES-GCM, or you are
faced with
picking your poison.

Putting RC4 first hurts modern browsers that want it on for backwards
compat. Putting
TLS_3DES_EDE_SHA1 (I might not have that right) first doesn't, and
makes the best
attack active over passive. But the average sysadmin doesn't make the
right call: our
RFC would tell them to change the configuration to disable RC4.

>
> Since I know there are a lot of knowledgeable people who care about secur=
ity at
> google, I might be missing something here.

They've been pushing Chrome for years: when I connect to gmail, it's
with AES-GCM over TLS 1.2
and ECDH_ECDSA.
>
> Manuel.
>
> _______________________________________________
> 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 watsonbladd@gmail.com  Mon Dec 30 15:18:32 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE631AE207 for ; Mon, 30 Dec 2013 15:18:32 -0800 (PST)
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 NjMtPzGdgnJK for ; Mon, 30 Dec 2013 15:18:30 -0800 (PST)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id AD9D81AE2AC for ; Mon, 30 Dec 2013 15:18:29 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id hm19so12057154wib.1 for ; Mon, 30 Dec 2013 15:18:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cpYtUzKqU3H7HOW75fsORUY5CfYMdIlSZiOJNoGdqlI=; b=Sysd3az7W3lWnMS+K+Aa7WFeExRKjJ9h2jrTNhypPURBPtJbNfi7QEV3X8VtrzYJ0X qhVIN2ljdU7NRPGoR/UqOpxG0bnl9Kpf+IvT+GZkzlPiv/SHzSmfJqdXeBWPt0v1DXns n7DtxKeV5e58RayRaO+5zz/YyIRHa86FyTOnae0eth7JvGb/07GCXgedMkIVcZP9Kouq POFIecSzqw0Zx6IAOUk0IcI/2axlBli8GkqktFVlCkwjJ21ZLntrYVrfVrnRrbcUVBFk 8pJkvgNxTj2FVne9abip/zKqdoUzN/+6z2TCKc1nkYOlMwseMig6VgFtuyRn0kcPlzf4 Q1ug==
MIME-Version: 1.0
X-Received: by 10.180.86.9 with SMTP id l9mr45704456wiz.20.1388445503126; Mon, 30 Dec 2013 15:18:23 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 30 Dec 2013 15:18:23 -0800 (PST)
In-Reply-To: <52C1EB13.3050909@akr.io>
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> <52C160B4.10103@akr.io> <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com> <52C1BEF1.4030406@akr.io> <52C1D5C8.7060702@polarssl.org> <52C1EB13.3050909@akr.io>
Date: Mon, 30 Dec 2013 18:18:23 -0500
Message-ID: 
From: Watson Ladd 
To: Alyssa Rowan 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Dec 2013 23:18:33 -0000

On Mon, Dec 30, 2013 at 4:52 PM, Alyssa Rowan  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 30/12/2013 20:21, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote:
>
>> What is the group's opinion on using HMAC-SHA256/384 suites with
>> TLS < 1.2?
>
> Why stop there? We had the SHA-3 competition last year: if we intend
> to replace SHA-1, why use SHA-2?
>
> The competition yielded five excellent replacements, some of which are
> faster than SHA-2=C2=B9, none of which were designed by the NSA=C2=B2, an=
d none
> of which have length-extension attacks=C2=B3: Keccak (selected by NIST as
> SHA-3), Skein, BLAKE, JH and Gr=C3=B8stl.
>
> Perhaps we should make our own determination and/or take advice from
> CFRG as to which of these might be suitable for future use in the
> alternative?
>
> To me, the leading three from the SHA-3 finalists are:
>
> =E2=80=A2 Keccak (SHA-3):
>   - Poorish software performance: roughly SHA-2 speed or slower.
>   - Not as well analysed as some other SHA-3 candidates.
>   - NIST-approved. (Is this a positive or negative now? )
>   - Possible _future_ good hardware performance, due to being selected
>     as SHA-3: not likely to be relevant for years yet, however.
>   - NIST didn't eventually make any midnight-hour changes: trust issues.
> =E2=80=A2 Skein:
>   - 72 round fast ARX tweakable block cipher core with a smooth finish.
>   - Excellent software performance - roughly 2=C3=97 SHA-2 & SHA-3 speed.
>   - Very well-analysed.
> =E2=80=A2 BLAKE:
>   - Based on a tweaked ChaCha14/ChaCha16, lengthways and diagonally.
>   - Excellent software performance, competitive w/ Skein (just loses)
>   - Very well-analysed.
>
> JH or Gr=C3=B8stl are slower so not as attractive.
>
> While Skein was my favoured of the bunch in general, I note the
> delicious symmetry of BLAKE being based upon a slightly modified
> version of the stream cipher we're planning to use.
>
> I'd therefore tentatively suggest ChaCha20_HMAC-BLAKE256 as a TLS 1.0/
> 1.1 alternative to ChaCha20_Poly1305, if it's thought appropriate
> (CFRG?), and I'd suggest that over and above HMAC-SHA256.
>
> And software performance right now I feel is more relevant for the
> ChaCha20 ciphersuites, because those are especially good for platforms
> where AES & GCM hardware acceleration isn't available, and it's hard
> to suppose of a future platform that would accelerate SHA-3 but not
> AES or GCM.
>
> Whereas for TLS 1.3, perhaps I could see SHA-3 as a NIST-selected
> alternative alongside Skein or BLAKE, for possible future agility.
>
> Thoughts?

Even if SHA-1 is utterly broken, this won't necessarily break HMAC based on=
 it.

I also don't like the idea of backporting: if we are going to be
patching systems and forcing
upgrades, why not to TLS 1.2 which doesn't have these issues?

Chacha20+Poly1305 is a good addition to TLS 1.2 for devices without
hardware support.

When it comes to hash functions, negotiating the use of the hash
function in the handshake doesn't
solve anything: if the hash function to which you feed the handshake
is broken enough to allow for interfering
with the handshake, then the attacker can dictate it. It takes a very
broken hash function to make key negotiation
with it a bad idea, and HMAC has similar robustness. I don't think
SHA256 is going to fall that way. (In particular,
the data the attacker can influence goes after the ciphersuites used

The one place we really depend on hash functions is in the signatures
that tie the key negotiation to the certificate
chain. There are ways around it like MQV, but that is patented. SHA256
has been more resistant than expected here,
but we certainly could put some flexibility in in TLS 1.3 without
hurting latency.

Sincerely,
Watson Ladd
>
> ___
> 1. Current performance: 
> 2. I don't think the NSA intentionally weakened SHA-2. It's OK,
>    length-extension aside. But we can have more independent confidence
>    in something they didn't design.
> 3. Which resulted in NIST calling the SHA-3 competition.
>
> - --
> /akr
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJSwesSAAoJEOyEjtkWi2t6uugP/2wQLTWKCfoubEmYl1D/wVEv
> BKo38oNJHQoKmJOgqUmoRYp4BDzeVcNDsllnESIJi5uc3O/tkIoTCgbbpiAO0tW3
> MH2c+Hg3Qf+BjjbovMDf45ekFkz3+3onR1TI2Vh6tMP2fybbAiBZXZ2fWpdk0d5H
> wArhOV4nBXWDPnjCNJpvstOwaXmR3cgkE7tNwMUXXJ7Dr4mm93kYpaM+ztAQ/DZj
> VHA5AfX4JRXajK3S5qkmJdZokMWDU7VPkt58AcyCudRCZY/ROFuqRe2H3E8ryG5J
> VXYqGLYxUrsagFCahYBwYbpGXtiHs6Jveb+MAdsB7ZOmGpPlkKijzGQs7CGOcnFb
> 35fH+steCMskZbaS5pq0+47TdFkIIvWCobiPso8s4ohP1k1zF78dki9/cWMQ8U4W
> DpxWKrE0WDYDogpLXtmomoF3W5CFYNXBIMHBrcyP1nLthqSGDwL8FHGvOlQ/1gOW
> p51CeNrOOVGK11dX90A/u5zRwXgn8PjoiT+tJ/DjznCuTcLphKeNU1SdNg5jxYeZ
> 98Wqp5QBs9U+Cdfqoncp2fYOiLt0RcVCbb1uO5ps2dyPkTNSSswhF5SSM82OK4N3
> /ZqF1v7ZWp2YJ/3tRH87pXXztenTAovITQsbT6Fxswx2dKmHMUHmOSXCfFyCl+As
> GT3gIhkHm2wMsanNAoZE
> =3Dw3Z3
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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 mpg@polarssl.org  Mon Dec 30 16:46:50 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0B41AE32B for ; Mon, 30 Dec 2013 16:46:50 -0800 (PST)
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 7HNaP_JFsZev for ; Mon, 30 Dec 2013 16:46:49 -0800 (PST)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id E993C1AE334 for ; Mon, 30 Dec 2013 16:46:48 -0800 (PST)
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=kuvN5z3pPeUFaT7MxZKkxuxKWLYqj7KEEgOBMWwaz84=;  b=Mwl/H7PP+pAEKyIKIqMsbzYm4ZzZGvzcTPr9VTG4BzLHterMApXHBFiqcJi7/3XIKuuN+kze+1eFj00LGARw5yFIjTzSFH3Jgd5HE1roFiGudIhhcCGhBv9THbzPebXxkK1dFj0EGKtU4gC9XDtUBmN7CKDgBV7osc5yYPhGSXQ=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VxnMj-0007YE-8J for tls@ietf.org; Tue, 31 Dec 2013 01:39:25 +0100
Message-ID: <52C213F2.5040809@polarssl.org>
Date: Tue, 31 Dec 2013 01:46:42 +0100
From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1
MIME-Version: 1.0
To: tls@ietf.org
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> <52C160B4.10103@akr.io> <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com> <52C1BEF1.4030406@akr.io> <52C1D5C8.7060702@polarssl.org> <52C1EB13.3050909@akr.io> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
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)
Subject: Re: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 31 Dec 2013 00:46:50 -0000

On 31/12/2013 00:18, Watson Ladd wrote:
> Even if SHA-1 is utterly broken, this won't necessarily break HMAC
> based on it.
> 
> I also don't like the idea of backporting: if we are going to be
> patching systems and forcing
> upgrades, why not to TLS 1.2 which doesn't have these issues?
> 
Well, that was more or less my question: is using SHA-2 for HMAC with
TLS < 1.2 really backporting? I just checked RFC 2246 and 4346 and they
both state:

    Additional hash algorithms can be defined by cipher suites and
    used to protect record data, but MD5 and SHA-1 are hard coded into
    the description of the handshaking for this version of the protocol.

So, I'm really under the impression that there is nothing that prevents
anyone from defining a SHA-2 ciphersuite and using it with TLS < 1.2,
with the understanding that the PRF (hence the handshake authentication)
remains based on MD5 + SHA1.

However, a number of facts (akr's recent message, the restriction in RFC
5932, the fact that neither OpenSSL nor GnuTLS accepts to negotiate any
SHA-2 suite with TLS < 1.2) seems to indicate otherwise, so I wanted to
check if I missed some good reason not to use SHA-2 suites with TLS <
1.2.

Manuel.

From ekr@rtfm.com  Mon Dec 30 16:48:20 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8823D1AE56E for ; Mon, 30 Dec 2013 16:48:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 LLYiNhq25i-q for ; Mon, 30 Dec 2013 16:48:18 -0800 (PST)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id A08E81AE56D for ; Mon, 30 Dec 2013 16:48:18 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id hq4so16141538wib.1 for ; Mon, 30 Dec 2013 16:48:12 -0800 (PST)
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:content-transfer-encoding; bh=aSiIUligLURrmEcNNTrvj8TPY3ogu3v67VLtgDa4lt8=; b=Z8/O6b1lQG0DgPOXN8lV03L16gQAUeiPWg1rlCzS1mwSrmZgsFusnKRiCOSyXed4N/ n6+dDssONIFBJhcxarVPAC6+ihMadJgCLTU48I6fEaecf7c9sul8BkTLtMprO6wQdpwr pT519rjBk1fklbBkib+JlIqNCB3opuHviUeaOoIWq7md4HED8tlMyJy7Fe2cUyCaaZmu bWc5uIjH8LZZMX/Mqr6MgMFdFPpVnBoAMm+Dmj7tu4xvoVSTzpZugA4RvO1d0DRQLvag pKvBgEHDxjb1fS/wGGlhKPZwwF//ky4cHYfj5EAHCjvWjTwVWFX0e/jQF7v5pW2z32vi qZnw==
X-Gm-Message-State: ALoCoQm63vxjLgLkxftufh1WmGNHc/Cgx8S3rCIC/bFUERTh0MkncLciQ8Oxeho82x1xQbW2zalm
X-Received: by 10.194.187.101 with SMTP id fr5mr1813049wjc.76.1388450892140; Mon, 30 Dec 2013 16:48:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Mon, 30 Dec 2013 16:47:32 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <52C1D5C8.7060702@polarssl.org>
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> <52C160B4.10103@akr.io> <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com> <52C1BEF1.4030406@akr.io> <52C1D5C8.7060702@polarssl.org>
From: Eric Rescorla 
Date: Mon, 30 Dec 2013 16:47:32 -0800
Message-ID: 
To: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9=2DGonnard?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 31 Dec 2013 00:48:20 -0000

On Mon, Dec 30, 2013 at 12:21 PM, Manuel P=E9gouri=E9-Gonnard
 wrote:
> [forking thread for discussion on a side point]
>
> On 30/12/2013 19:44, Alyssa Rowan wrote:
>>   - TLS 1.1/1.0: ChaCha20_SHA { draft-mavrogiannopoulos-chacha20-tls }
>> [...]
>>     =B7 Not loving having to use HMAC_SHA1 but TLS 1.0/1 is stuck with i=
t
>>
> Are we really stuck with SHA1 (as opposed to SHA-256 or SHA-384) for HMAC=
 on TLS
> 1.0 and 1.1?

It's probably useful to start by discussing the threat model. TLS uses
digests for four
primary purposes:

- To verify signatures on certificates.
- To verify other signatures (arguably this is the same as
certificates, but I am breaking
  it out here for ease of explanation.)
- In the MAC (HMAC)
- As part of the KDF

By far the easiest of these to replace is the MAC, since it's part of
the cipher suite.
There's nothing stopping us defining a new cipher suite (even for TLS 1.0) =
that
uses some other MAC with another hash [0]. Changing the other usages has
a variety of challenges, which is where the machinery from TLS 1.2 comes in=
.

With that said, my impression is that the use of SHA-1 in HMAC is comparati=
vely
strong to use for digital signatures (and of course, the impact is far less=
 than
if someone can forge a certificate signature). And for the usual
deployment reasons
we are likely stuck with SHA-1-based certificates and clients that accept t=
hem
for quite some time. Note that even if you support TLS 1.2, you
probably still have
to accept SHA-1 for interop reasons. [1]

With that in mind, how much extra security benefit do we get from replacing
HMAC-SHA1 with HMAC-, as long as we still have SHA-1 for certifi=
cates
and signatures? And if we're considering only replacing the MAC, it seems l=
ike
it might make sense to go with a MAC that is not hash based at all.

-Ekr



[0] This is specified, at least in 2246, as HMAC
(http://tools.ietf.org/html/rfc2246#section-6.2.3.1)
but technically it wouldn't be hard to write a new ciphersuite overriding t=
his.

[1] For instance, my current connection with Chrome to Google uses
AES-GCM but the
cert is RSA-SHA1.



> At least three RFCs (5487, 5489 and 6367) that define ciphersuites with
> HMAC-SHA2 explicitly allow them to be used with TLS < 1.2. Quoting from R=
FC 6367
> (section 3.3) for example:
>
>    The hash algorithms and pseudorandom function (PRF) algorithms for
>    TLS 1.2 [8] SHALL be as follows:
>
>    a.  The cipher suites ending with _SHA256 use HMAC-SHA-256 [1] as the
>        MAC algorithm.  The PRF is the TLS PRF [8] with SHA-256 [13] as
>        the hash function.
>
>    b.  The cipher suites ending with _SHA384 use HMAC-SHA-384 [1] as the
>        MAC algorithm.  The PRF is the TLS PRF [8] with SHA-384 [13] as
>        the hash function.
>
>    When used with TLS versions prior to 1.2 (TLS 1.0 [2] and TLS 1.1
>    [6]), the PRF is calculated as specified in the appropriate version
>    of the TLS specification.
>
> On the other hand, at least one other RFC that defines SHA-2 and ciphersu=
ites
> explicitly prohibits their use with TLS < 1.2. Quoting from RFC 5932 3.3.=
3:
>
>    The cipher suites ending with _SHA256 use HMAC-SHA-256 as the MAC
>    algorithm.  The PRF is the TLS PRF [RFC5246] with SHA-256 as the hash
>    function.  These cipher suites MUST NOT be negotiated by TLS 1.1 or
>    earlier versions.  Clients MUST NOT offer these cipher suites if they
>    do not offer TLS 1.2 or later.  Servers that select an earlier
>    version of TLS MUST NOT select one of these cipher suites.
>
> At least one other RFC (5289) defines SHA-2 suites without any hint about
> whether they can be used with TLS < 1.2 or not. (We count even count RFC =
5246 in
> this category.)
>
> It seems to me that allowing HMAC-SHA256/384 with TLS 1.0 and 1.1 should =
not be
> a problem for implementers. At least, I didn't see a problem when lowerin=
g the
> version requirements for the ciphersuites from RFCs that allow them with =
< 1.2
> in PolarSSL, but on the other hand I couldn't test interop since I was un=
able to
> find another implementation that uses those SHA-2 suites with TLS < 1.2..=
.
>
> What is the group's opinion on using HMAC-SHA256/384 suites with TLS < 1.=
2?
>
> Manuel.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

From pgut001@cs.auckland.ac.nz  Mon Dec 30 18:20:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB5A1AE2BD for ; Mon, 30 Dec 2013 18:20:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.538] 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 39h3SCHbpr5W for ; Mon, 30 Dec 2013 18:20:47 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 560E31AE2FF for ; Mon, 30 Dec 2013 18:20:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1388456441; x=1419992441; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=kQVEg7XoIdPBy/jBWAfk4/N7i8RuJgOV28FBAjUR1Z4=; b=Ps7DnG7++MsHiBOsNen9jcqO5UILPhMfJ6kYJbwuwDryBDDm9vC4Uvxm kDganTq3H+nblI1Dn8jOYSvGa8c7cmn7XASYll+twC2YLJgbmKGRkRKtF Scd+ppvdUC1K6Pq8uNCJv48vSO8h5+skZ+GaC7+FMjzNvYIN72+ESWAkw w=;
X-IronPort-AV: E=Sophos;i="4.95,577,1384254000"; d="scan'208";a="228262258"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 31 Dec 2013 15:20:38 +1300
Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.205]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0158.001; Tue, 31 Dec 2013 15:20:37 +1300
From: Peter Gutmann 
To: "tls@ietf.org" 
Thread-Topic: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01
Thread-Index: Ac8FzuRuK8+0YCuUTO2vxkoPDmsH5Q==
Date: Tue, 31 Dec 2013 02:20:37 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C737234F1DE@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
Subject: Re: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 31 Dec 2013 02:20:51 -0000

Watson Ladd  writes:=0A=
=0A=
>Even if SHA-1 is utterly broken, this won't necessarily break HMAC based o=
n=0A=
>it.=0A=
=0A=
Exactly.  SHA-1 and HMAC-SHA1 are very different things, and concerns about=
=0A=
SHA-1 don't really affect HMAC-SHA1.=0A=
=0A=
Peter.=

From SChokhani@cygnacom.com  Mon Dec 30 18:28:03 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9501AE372 for ; Mon, 30 Dec 2013 18:28:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.139
X-Spam-Level: 
X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, 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 zpJvbhj9xaEH for ; Mon, 30 Dec 2013 18:28:00 -0800 (PST)
Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 34C761AE2BD for ; Mon, 30 Dec 2013 18:28:00 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.95,577,1384318800";  d="scan'208";a="1579079"
Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 30 Dec 2013 21:27:51 -0500
Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62%15]) with mapi id 14.02.0247.003; Mon, 30 Dec 2013 21:27:52 -0500
From: Santosh Chokhani 
To: Eric Rescorla , =?iso-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= 
Thread-Topic: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01
Thread-Index: AQHPBZy8R3eit1tqDEOi3UDVch5D5JptzF8A///HY+A=
Date: Tue, 31 Dec 2013 02:27:51 +0000
Message-ID: <4262AC0DB9856847A2D00EF817E811391047E3@scygexch10.cygnacom.com>
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> <52C160B4.10103@akr.io> <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com> <52C1BEF1.4030406@akr.io> <52C1D5C8.7060702@polarssl.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.60.24.84]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on	draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 31 Dec 2013 02:28:03 -0000

Eric,

I would think that it would be appropriate to break out use of SHA-1 for ve=
rifying signature on the certificate from other usages of SHA-1 to verify s=
ignatures on ephemeral keys and client authentication, etc.

We know that use of weak hash can be exploited by an attacker depending on =
how certificates are issued.

But, for signatures by the client and the server on the keys or authenticat=
ion, I do not think there is a collision motivation and hence SHA-1 would b=
e ok there.

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Monday, December 30, 2013 7:48 PM
To: Manuel P=E9gouri=E9-Gonnard
Cc: tls@ietf.org
Subject: Re: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-=
prohibiting-rc4-01

On Mon, Dec 30, 2013 at 12:21 PM, Manuel P=E9gouri=E9-Gonnard  wrote:
> [forking thread for discussion on a side point]
>
> On 30/12/2013 19:44, Alyssa Rowan wrote:
>>   - TLS 1.1/1.0: ChaCha20_SHA { draft-mavrogiannopoulos-chacha20-tls=20
>> } [...]
>>     =B7 Not loving having to use HMAC_SHA1 but TLS 1.0/1 is stuck with=20
>> it
>>
> Are we really stuck with SHA1 (as opposed to SHA-256 or SHA-384) for=20
> HMAC on TLS
> 1.0 and 1.1?

It's probably useful to start by discussing the threat model. TLS uses dige=
sts for four primary purposes:

- To verify signatures on certificates.
- To verify other signatures (arguably this is the same as certificates, bu=
t I am breaking
  it out here for ease of explanation.)
- In the MAC (HMAC)
- As part of the KDF

By far the easiest of these to replace is the MAC, since it's part of the c=
ipher suite.
There's nothing stopping us defining a new cipher suite (even for TLS 1.0) =
that uses some other MAC with another hash [0]. Changing the other usages h=
as a variety of challenges, which is where the machinery from TLS 1.2 comes=
 in.

With that said, my impression is that the use of SHA-1 in HMAC is comparati=
vely strong to use for digital signatures (and of course, the impact is far=
 less than if someone can forge a certificate signature). And for the usual=
 deployment reasons we are likely stuck with SHA-1-based certificates and c=
lients that accept them for quite some time. Note that even if you support =
TLS 1.2, you probably still have to accept SHA-1 for interop reasons. [1]

With that in mind, how much extra security benefit do we get from replacing
HMAC-SHA1 with HMAC-, as long as we still have SHA-1 for certifi=
cates and signatures? And if we're considering only replacing the MAC, it s=
eems like it might make sense to go with a MAC that is not hash based at al=
l.

-Ekr



[0] This is specified, at least in 2246, as HMAC
(http://tools.ietf.org/html/rfc2246#section-6.2.3.1)
but technically it wouldn't be hard to write a new ciphersuite overriding t=
his.

[1] For instance, my current connection with Chrome to Google uses AES-GCM =
but the cert is RSA-SHA1.



> At least three RFCs (5487, 5489 and 6367) that define ciphersuites=20
> with
> HMAC-SHA2 explicitly allow them to be used with TLS < 1.2. Quoting=20
> from RFC 6367 (section 3.3) for example:
>
>    The hash algorithms and pseudorandom function (PRF) algorithms for
>    TLS 1.2 [8] SHALL be as follows:
>
>    a.  The cipher suites ending with _SHA256 use HMAC-SHA-256 [1] as the
>        MAC algorithm.  The PRF is the TLS PRF [8] with SHA-256 [13] as
>        the hash function.
>
>    b.  The cipher suites ending with _SHA384 use HMAC-SHA-384 [1] as the
>        MAC algorithm.  The PRF is the TLS PRF [8] with SHA-384 [13] as
>        the hash function.
>
>    When used with TLS versions prior to 1.2 (TLS 1.0 [2] and TLS 1.1
>    [6]), the PRF is calculated as specified in the appropriate version
>    of the TLS specification.
>
> On the other hand, at least one other RFC that defines SHA-2 and=20
> ciphersuites explicitly prohibits their use with TLS < 1.2. Quoting from =
RFC 5932 3.3.3:
>
>    The cipher suites ending with _SHA256 use HMAC-SHA-256 as the MAC
>    algorithm.  The PRF is the TLS PRF [RFC5246] with SHA-256 as the hash
>    function.  These cipher suites MUST NOT be negotiated by TLS 1.1 or
>    earlier versions.  Clients MUST NOT offer these cipher suites if they
>    do not offer TLS 1.2 or later.  Servers that select an earlier
>    version of TLS MUST NOT select one of these cipher suites.
>
> At least one other RFC (5289) defines SHA-2 suites without any hint=20
> about whether they can be used with TLS < 1.2 or not. (We count even=20
> count RFC 5246 in this category.)
>
> It seems to me that allowing HMAC-SHA256/384 with TLS 1.0 and 1.1=20
> should not be a problem for implementers. At least, I didn't see a=20
> problem when lowering the version requirements for the ciphersuites=20
> from RFCs that allow them with < 1.2 in PolarSSL, but on the other=20
> hand I couldn't test interop since I was unable to find another implement=
ation that uses those SHA-2 suites with TLS < 1.2...
>
> What is the group's opinion on using HMAC-SHA256/384 suites with TLS < 1.=
2?
>
> Manuel.
> _______________________________________________
> 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 msj@nthpermutation.com  Mon Dec 30 19:39:08 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4F01AE38C for ; Mon, 30 Dec 2013 19:39:08 -0800 (PST)
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 YF7SVh3GZfAe for ; Mon, 30 Dec 2013 19:39:05 -0800 (PST)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id C016D1AE2B8 for ; Mon, 30 Dec 2013 19:39:05 -0800 (PST)
Received: by mail-qc0-f176.google.com with SMTP id i8so11647125qcq.35 for ; Mon, 30 Dec 2013 19:38:59 -0800 (PST)
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=wV2iQZrNBBu4mJAs03XWMTgYw1PyYuLg41DHWCdLuvQ=; b=lyPZvVdTFYlbQjzzIfDmHC6JgUmD/R+FELy7jCln7ZjWR5JPuRY8++mJHqiH+Iyiqf UzlZsPyBSzHR//rDkAPpltso5G110nu/9gQg6UHYU0OkUWcJ1ULe2L/LJATwl9nnARQd ihCYiPMNL1klGTmo9SqVphwYBj4449zWVAZjKkf0zCfP8gSwoN+70ZLkkYJQLH3sF7NI nKjOPz7QOUjUuPlkVfeH62E8RHPBAlzs0Cvqqsn6R7uad5MwWRx0a0LlJ2SKwx1IAPGU W7LCgax1josXAzd1Ke9pPXv8axe9MtFOrnilqnWuOMQnRUJ0mAopCAwozatFQPBUYJpy pu1g==
X-Gm-Message-State: ALoCoQm2/woKeZP4K3oJSxJVekYSE9/+siVrbJc4y5+iN0r7wb9XtYEEVlxbb8IRhoP/JraiGhpv
X-Received: by 10.49.2.132 with SMTP id 4mr116329111qeu.15.1388461138443; Mon, 30 Dec 2013 19:38:58 -0800 (PST)
Received: from [192.168.1.112] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id d1sm69055239qai.7.2013.12.30.19.38.57 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Dec 2013 19:38:57 -0800 (PST)
Message-ID: <52C23C52.1050003@nthpermutation.com>
Date: Mon, 30 Dec 2013 22:38:58 -0500
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tls@ietf.org
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> <52C160B4.10103@akr.io> <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com> <52C1BEF1.4030406@akr.io> <52C1D5C8.7060702@polarssl.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 31 Dec 2013 03:39:08 -0000

On 12/30/2013 7:47 PM, Eric Rescorla wrote:
> On Mon, Dec 30, 2013 at 12:21 PM, Manuel Pégourié-Gonnard
>  wrote:
>> [forking thread for discussion on a side point]
>>
>> On 30/12/2013 19:44, Alyssa Rowan wrote:
>>>    - TLS 1.1/1.0: ChaCha20_SHA { draft-mavrogiannopoulos-chacha20-tls }
>>> [...]
>>>      · Not loving having to use HMAC_SHA1 but TLS 1.0/1 is stuck with it
>>>
>> Are we really stuck with SHA1 (as opposed to SHA-256 or SHA-384) for HMAC on TLS
>> 1.0 and 1.1?
> It's probably useful to start by discussing the threat model. TLS uses
> digests for four
> primary purposes:
>
> - To verify signatures on certificates.
> - To verify other signatures (arguably this is the same as
> certificates, but I am breaking
>    it out here for ease of explanation.)
> - In the MAC (HMAC)
> - As part of the KDF
There's also:
To verify the finish message (but this could easily be a CMAC or GMAC).
To produce public pseudo-random data (this is done currently as part of 
the key expansion step, but arguably shouldn't be).

Let me split this up a bit differently:

TLS1.2 (hardwired protocol) uses a PRF function for the KDF, for the MAC 
over the finish message and for producing pseudo-random data. The 
generic PRF is based on HMAC-SHA256, but there's no reason that the PRF 
needs to be based on a hash.

Suites MAY use a hash as part of a certificate signature verification 
(but not necessarily - i.e. PSK suites), and for MAC (again, not 
necessarily - i.e. CMAC or CCM suites).


Out of all of these, the one where hashes are most deeply embedded and 
where this WG has the least ability to affect change is certificates.  
(I agree with your comment below that we're not likely to be able to 
change this in the near future).

>
> By far the easiest of these to replace is the MAC, since it's part of
> the cipher suite.
> There's nothing stopping us defining a new cipher suite (even for TLS 1.0) that
> uses some other MAC with another hash [0]. Changing the other usages has
> a variety of challenges, which is where the machinery from TLS 1.2 comes in.
>
> With that said, my impression is that the use of SHA-1 in HMAC is comparatively
> strong to use for digital signatures (and of course, the impact is far less than
> if someone can forge a certificate signature). And for the usual
> deployment reasons
> we are likely stuck with SHA-1-based certificates and clients that accept them
> for quite some time. Note that even if you support TLS 1.2, you
> probably still have
> to accept SHA-1 for interop reasons. [1]
>
> With that in mind, how much extra security benefit do we get from replacing
> HMAC-SHA1 with HMAC-, as long as we still have SHA-1 for certificates
> and signatures? And if we're considering only replacing the MAC, it seems like
> it might make sense to go with a MAC that is not hash based at all.

I think you have to talk about this as replacing the base function for 
the PRF (unless you want to respec TLS1.2?).

Assuming there's no security issue with replacing the HMAC in the PRF 
with a CMAC, you could define a PSK suite that could be implemented with 
nothing more than the AES encrypt operation. (e.g. 
TLS_PSK_WITH_AES_128_CCM_CMAC)

I think you'd have to define some adaptations though  - an HMAC can take 
a key of any length, while a CMAC requires a key of length of the 
underlying block cipher.

Mike




>
> -Ekr
>
>
>
> [0] This is specified, at least in 2246, as HMAC
> (http://tools.ietf.org/html/rfc2246#section-6.2.3.1)
> but technically it wouldn't be hard to write a new ciphersuite overriding this.
>
> [1] For instance, my current connection with Chrome to Google uses
> AES-GCM but the
> cert is RSA-SHA1.
>
>
>
>> At least three RFCs (5487, 5489 and 6367) that define ciphersuites with
>> HMAC-SHA2 explicitly allow them to be used with TLS < 1.2. Quoting from RFC 6367
>> (section 3.3) for example:
>>
>>     The hash algorithms and pseudorandom function (PRF) algorithms for
>>     TLS 1.2 [8] SHALL be as follows:
>>
>>     a.  The cipher suites ending with _SHA256 use HMAC-SHA-256 [1] as the
>>         MAC algorithm.  The PRF is the TLS PRF [8] with SHA-256 [13] as
>>         the hash function.
>>
>>     b.  The cipher suites ending with _SHA384 use HMAC-SHA-384 [1] as the
>>         MAC algorithm.  The PRF is the TLS PRF [8] with SHA-384 [13] as
>>         the hash function.
>>
>>     When used with TLS versions prior to 1.2 (TLS 1.0 [2] and TLS 1.1
>>     [6]), the PRF is calculated as specified in the appropriate version
>>     of the TLS specification.
>>
>> On the other hand, at least one other RFC that defines SHA-2 and ciphersuites
>> explicitly prohibits their use with TLS < 1.2. Quoting from RFC 5932 3.3.3:
>>
>>     The cipher suites ending with _SHA256 use HMAC-SHA-256 as the MAC
>>     algorithm.  The PRF is the TLS PRF [RFC5246] with SHA-256 as the hash
>>     function.  These cipher suites MUST NOT be negotiated by TLS 1.1 or
>>     earlier versions.  Clients MUST NOT offer these cipher suites if they
>>     do not offer TLS 1.2 or later.  Servers that select an earlier
>>     version of TLS MUST NOT select one of these cipher suites.
>>
>> At least one other RFC (5289) defines SHA-2 suites without any hint about
>> whether they can be used with TLS < 1.2 or not. (We count even count RFC 5246 in
>> this category.)
>>
>> It seems to me that allowing HMAC-SHA256/384 with TLS 1.0 and 1.1 should not be
>> a problem for implementers. At least, I didn't see a problem when lowering the
>> version requirements for the ciphersuites from RFCs that allow them with < 1.2
>> in PolarSSL, but on the other hand I couldn't test interop since I was unable to
>> find another implementation that uses those SHA-2 suites with TLS < 1.2...
>>
>> What is the group's opinion on using HMAC-SHA256/384 suites with TLS < 1.2?
>>
>> Manuel.
>> _______________________________________________
>> 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 akr@akr.io  Mon Dec 30 19:42:42 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2731AE43E for ; Mon, 30 Dec 2013 19:42:42 -0800 (PST)
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 LLwjfgPjo5-0 for ; Mon, 30 Dec 2013 19:42:39 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2195D1AE2B8 for ; Mon, 30 Dec 2013 19:42:39 -0800 (PST)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id 41A9C603FC for ; Tue, 31 Dec 2013 03:42:32 +0000 (GMT)
Message-ID: <52C23D13.6000708@akr.io>
Date: Tue, 31 Dec 2013 03:42:11 +0000
From: Alyssa Rowan 
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C737234F1DE@uxcn10-tdc06.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C737234F1DE@uxcn10-tdc06.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 31 Dec 2013 03:42:42 -0000

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

On 31/12/2013 02:20, Peter Gutmann wrote:
> Exactly.  SHA-1 and HMAC-SHA1 are very different things, and 
> concerns about SHA-1 don't really affect HMAC-SHA1.

On 30/12/2013 23:18, Watson Ladd wrote:
> Even if SHA-1 is utterly broken, this won't necessarily break HMAC 
> based on it.

Fair point. There's nothing to currently suggest the NSA have a
preimage on SHA-1, especially not one that'd endanger HMAC, unless (of
course) I've missed something, or just don't know something!

It's not ideal; it's not as good as Poly1305; but especially as a
fallback, it's not cataclysmic.

On 30/12/2013 23:18, Watson Ladd wrote:
> I also don't like the idea of backporting: if we are going to be 
> patching systems and forcing upgrades, why not to TLS 1.2 which 
> doesn't have these issues?

Complex question. Why not indeed? The deployment/inertia issue.

• TLS1.2 server / intolerant clients?
• TLS1.2 intolerant middleware?
  - Isn't that a dangerous downgrade?
• TLS1.2 client / intolerant servers?

I'm sure someone here (agl?) has specific "doghouse" examples of which
things are effectively holding back universal TLS1.2 deployment. These
might be useful as test cases: can we have a few names?

Clients with it but that don't turn it on by default (concern for
intolerant servers?) may be more common than we often think. To name a
few: Windows Schannel under Windows 7, Vista, IIS under 2008R2...
(Of course, they're still supported, and we could encourage MS to
issue an important patch enabling it... if people'd install it.)

Would a ChaCha20_SHA { draft-mavrogiannopoulos-chacha20-tls } that we
can still use with TLS1.0 & 1.1 be helpful as well as an fallback
augment to the better (and preferred) ChaCha20_Poly1305 for TLS 1.2?

• Downgrading: QUANTUMCOPPER can probably do this en-masse
  - As I said, we _really_ need { draft-bmoeller-tls-downgrade-scsv-01 }
  - But ChaCha20_SHA _might_ rescue us from using RC4_SHA
  - Unless, you know, they downgrade us back to SSLv3 and we don't bail
    on that. Then we're boned.
• Potential negative effect?
  - May be perceived as extending useful service life of TLS1.0 & 1.1
  - Simpler & less confusing to say TLS 1.0 and 1.1 are cooked?

Not sure about this one.

On 30/12/2013 23:18, Watson Ladd wrote:
> Chacha20+Poly1305 is a good addition to TLS 1.2 for devices without
> hardware support.

Absolutely agreed: and actually, I think it may be better than AES-GCM.

On 30/12/2013 23:18, Watson Ladd wrote:
> The one place we really depend on hash functions is in the 
> signatures that tie the key negotiation to the certificate chain. 
> There are ways around it like MQV, but that is patented.

Menezes-Qu-Vanstone had plenty of reasons to dislike it. Weaknesses;
patents; being dropped even from NSA Suite B; no PFS; HMQV also weak;
and with FHMQV we're back to being tied with hashes, so no point.

I reckon that's a dead-end. Besides, we've got good hash functions,
and can have excellent ones.

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

iQIcBAEBCgAGBQJSwj0TAAoJEOyEjtkWi2t6qpsP/j3j6KdAAF/OfCZ6G0fHIEmR
MLP7zshV4LXg66cnaV+l8gO+90bAQtyzQ3wZLp7h5QhXwVifW/yixRMUo/GcrOBV
kNwXghm7GxKF4Uls/1gOoCLO16TxRysrrOPplEaHVMNRVbJHh4CIe0o1GCBhyl/k
/T1ylRKJq/2CXiQW9prg8McaitKRovemjBL+u1/PWIVoFilpdYhjyfFlntgMLiZL
r73FAzc8RGJqF6qLveulEfrSj08E1Yam7GMyjDeiwvFBRqu5XY6zlgHNAa4dUpB5
icSVBTGhkRB6UzSv8uxYlXCiNIzHFkmA+XT/+lyKNKWGsouFoujbEldgdhpie9qr
l5+Qzxx2zxuD5VT3uaSLW1dlnjAWCHye7gF1Di0nhT2EJs89h+tWU4a7q5fFJgvA
67aiTvBKzxYx67/L/I1jQ4/u11MHAxoWkl+9NaQItc034s0mVNYgd+2pCoo7gxMX
3IhSOTPLVeYz0fS9iI2akUP6psPCICnDqbhq5qUB+i2LI6AHgLogfpJGNxypioJ1
MEdVS63Tv8NgEdGaPCL5G44/QTwXjYczNZTrNwf7yGAUf0/j776jJ37wxpkJFa7a
/HVt+mU4tKP+At0v23ApVQk0amToud0dwHwqW8GFjZPAJT0u36G9d6NmbMvVTpv8
5ZDNzgHum7TCpw3SBDKj
=BpH8
-----END PGP SIGNATURE-----

From ekr@rtfm.com  Mon Dec 30 20:01:42 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2B81AE3BF for ; Mon, 30 Dec 2013 20:01:42 -0800 (PST)
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 HSoO4QNskb32 for ; Mon, 30 Dec 2013 20:01:41 -0800 (PST)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 04DBB1AE3A4 for ; Mon, 30 Dec 2013 20:01:40 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id z2so12159760wiv.6 for ; Mon, 30 Dec 2013 20:01:34 -0800 (PST)
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=ONfBU0pBxyVjF/XxMEceJZ7vOgGNMK/wSbZg0WWzd4Q=; b=ZpEqujJpEl6mqKw7gg9Ve4XKsvNr6HKE3EBQLywAbb15lK/1ZGLVig54Mw/ny+UN43 12EekKdDnmLBcIeaNEZ8Tux8sSWhpU0lKfOdpDzeXyXh+Ccmnl5mwqWGsdtFK8nAsWuI 2yXtKYFgh3939m6tD4xjT16b1xGmzeYFhZaUoH8/05sthCWCCSVo1Y3B5scua991gFL/ t5p39KFjkv5QTlK72Ge0xxqTT5UQSpPvQToYiM281yDlaLE+23MecNw4lo6o4Se6e0lv jbtM3LpSCVW1oTM6W3/6+tooNFDudDiz745OdOujiTYPqn8RbuY5jy0etNSV3ci52M1L vi6w==
X-Gm-Message-State: ALoCoQl7e54chnuh0QGYDulLMSSl7Z+hVbNAOPFVwcnRskvxP3IdqsBSRD+Hj3CUPHP5Mg5KjEGZ
X-Received: by 10.194.240.41 with SMTP id vx9mr2159293wjc.70.1388462494411; Mon, 30 Dec 2013 20:01:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Mon, 30 Dec 2013 20:00:54 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <52C23C52.1050003@nthpermutation.com>
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> <52C160B4.10103@akr.io> <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com> <52C1BEF1.4030406@akr.io> <52C1D5C8.7060702@polarssl.org>  <52C23C52.1050003@nthpermutation.com>
From: Eric Rescorla 
Date: Mon, 30 Dec 2013 20:00:54 -0800
Message-ID: 
To: Michael StJohns 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 31 Dec 2013 04:01:42 -0000

On Mon, Dec 30, 2013 at 7:38 PM, Michael StJohns  wrote:
>> By far the easiest of these to replace is the MAC, since it's part of
>> the cipher suite.
>> There's nothing stopping us defining a new cipher suite (even for TLS 1.0)
>> that
>> uses some other MAC with another hash [0]. Changing the other usages has
>> a variety of challenges, which is where the machinery from TLS 1.2 comes
>> in.
>>
>> With that said, my impression is that the use of SHA-1 in HMAC is
>> comparatively
>> strong to use for digital signatures (and of course, the impact is far
>> less than
>> if someone can forge a certificate signature). And for the usual
>> deployment reasons
>> we are likely stuck with SHA-1-based certificates and clients that accept
>> them
>> for quite some time. Note that even if you support TLS 1.2, you
>> probably still have
>> to accept SHA-1 for interop reasons. [1]
>>
>> With that in mind, how much extra security benefit do we get from
>> replacing
>> HMAC-SHA1 with HMAC-, as long as we still have SHA-1 for
>> certificates
>> and signatures? And if we're considering only replacing the MAC, it seems
>> like
>> it might make sense to go with a MAC that is not hash based at all.
>
>
> I think you have to talk about this as replacing the base function for the
> PRF (unless you want to respec TLS1.2?).

Sorry, I was just talking about the message MAC, which you should
be able to change in all versions of TLS. And as I said above, I'm not
sure how useful that is in isolation.

-Ekr

From yaronf.ietf@gmail.com  Tue Dec 31 02:26:46 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513B51AE184; Tue, 31 Dec 2013 02:26:46 -0800 (PST)
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 qxqA9TqyW0Sa; Tue, 31 Dec 2013 02:26:44 -0800 (PST)
Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9511AE0AB; Tue, 31 Dec 2013 02:26:44 -0800 (PST)
Received: by mail-ee0-f42.google.com with SMTP id e53so5499507eek.1 for ; Tue, 31 Dec 2013 02:26:37 -0800 (PST)
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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=cCKlbu9tGl5JMVl3kVvSRlE35khPKICLP1D2isgSRUA=; b=qUMuk1VSepQsLuduE7C73DfaYd49V26o7CrJ1Kj4gzO2rfvhC3rqH1dgpFkqEI0jiZ P1jS81iyYND/xFJdbvjrgQuTRyNbAKo3lInWZlrrC/cOPOdYTRxev/ZNCH9osafNseBw mr8SENRBFRvN2xbJOEsJZkLyyigJ8aZ7o6RPtftg6fJQLAkvF943z3eXqma58oukgmoE e01vMyJW8GLogzUR2E8ZenodP2+BDwfVd/KoKtD+fEJwp9DmKyXUdj8nv7prUKEz08lg ywEFGfzMB42IRrInuttmvW6woZkUQWOokS2q0hwTUT2P/Vhgw1iztHvI+r9ciJoum7OX o41Q==
X-Received: by 10.14.199.197 with SMTP id x45mr59211778een.8.1388485597819; Tue, 31 Dec 2013 02:26:37 -0800 (PST)
Received: from [10.0.0.5] (85-250-26-178.bb.netvision.net.il. [85.250.26.178]) by mx.google.com with ESMTPSA id o1sm116849109eea.10.2013.12.31.02.26.36 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Dec 2013 02:26:37 -0800 (PST)
Message-ID: <52C29BD7.7030708@gmail.com>
Date: Tue, 31 Dec 2013 12:26:31 +0200
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Alyssa Rowan , tls@ietf.org, uta@ietf.org
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> <52C160B4.10103@akr.io> <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com> <52C1BEF1.4030406@akr.io>
In-Reply-To: <52C1BEF1.4030406@akr.io>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 31 Dec 2013 10:26:46 -0000

Hi Alyssa,

Thanks for the thorough analysis.

A quick background/motivation regarding the BCP - which of course is 
open to discussion.

The idea was to recommend only things that are currently standardized, 
and already widely (though definitely not universally) implemented. This 
strategy narrows the field down considerably, maybe too much, and 
precludes things like Nikos's ChaCha draft. But it means that with a bit 
of industry push, the RFC will be usable by *implementors* within 6-12 
months.

Thanks,
	Yaron

On 12/30/2013 08:44 PM, Alyssa Rowan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> (Hi to the UTA list. Crossposting because of the discussion pertaining
>   to a TLS BCP.)
>
> On 30/12/2013 15:20, Yoav Nir wrote:
>
>> Here's the thing. You, me, Yaron and Andrei can tell the world to
>> upgrade in an RFC. The world is not required to listen to us.
>
> Alas, so very true. I'm well aware the gulf between what we'd really
> like and what we can actually get is hard to bridge.
[snip]

>
> • Practical replacements we can roll out without ruffling feathers:
>    - TLS 1.2: ChaCha20_Poly1305 { draft-agl-tls-chacha20poly1305-01 }
>      · Faster than RC4
>      · 2^256 conf; 2^90 auth, ish
>      · Better than AES (side channel avoidance; apparently stronger)
>      · Requires TLS 1.2 because AEAD
>    - TLS 1.2: AES-128-GCM
>      · Already in TLS 1.2 (and NIST Suite B); deployment ongoing
>      · Complicated to avoid side-channels in software implementations
>      · But fast & good hardware support available on some platforms
>      · Requires TLS 1.2 because AEAD
>    - TLS 1.1/1.0: ChaCha20_SHA { draft-mavrogiannopoulos-chacha20-tls }
>      · Worse authenticator than ChaCha20_Poly1305
>      · But backwards-compatible with TLS 1.0 & TLS 1.1
>      · And much better than any other choice available there
>      · Good third choice; second, if AES-GCM not hardware accelerated
>      · Not loving having to use HMAC_SHA1 but TLS 1.0/1 is stuck with it
>      · When would this be useful? TLS 1.2-intolerant middleware? (Which?)
>
> • How can we encourage adoption?
>    - TLS BCP
>      · Being handled by (very new) UTA list
>      · Likely delay as a result; not ideal, but forward-thinking
>      · Try to get some momentum? (Thus, crossposted for discussion.)
>    - Once finished: point standard/compliance orgs to TLS BCP?
>      · PCI DSS might provide some incentive, even to geological-time
>        inertia of financial orgs? Maybe?
>      · Anyone else?
>    - Any other ideas?
>
> - --
> /akr
>

From Andrei.Popov@microsoft.com  Tue Dec 31 09:09:04 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23D51AE352 for ; Tue, 31 Dec 2013 09:09:04 -0800 (PST)
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 gwyCqr6q-AzM for ; Tue, 31 Dec 2013 09:09:00 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 3693B1AE1FE for ; Tue, 31 Dec 2013 09:09:00 -0800 (PST)
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.842.7; Tue, 31 Dec 2013 17:08: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.0842.003; Tue, 31 Dec 2013 17:08:47 +0000
From: Andrei Popov 
To: Eric Rescorla , Yoav Nir 
Thread-Topic: [TLS] Remarks on draft-popov-prohibiting-rc4-01
Thread-Index: AQHPBQ/X0InQ3GfMC0CpAMJ7Bn0Qk5psfwgAgAAktwCAADeXAIAADjqAgAGbCiA=
Date: Tue, 31 Dec 2013 17:08:47 +0000
Message-ID: <173dc4a849934f6d8223732da73b545e@BL2PR03MB419.namprd03.prod.outlook.com>
References:  <1D005EE9-AB66-42BE-98C3-058243DA7B1F@checkpoint.com> <52C160B4.10103@akr.io> <6338E7C0-B20E-43C9-B49A-33C47FE9901E@checkpoint.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [68.188.56.8]
x-forefront-prvs: 00770C4423
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(51704005)(189002)(199002)(13464003)(377454003)(479174003)(24454002)(54524002)(74706001)(69226001)(81342001)(74876001)(33646001)(74366001)(76576001)(76786001)(76796001)(74316001)(31966008)(81542001)(47446002)(74662001)(74502001)(87936001)(19580405001)(19580395003)(83322001)(54316002)(87266001)(56776001)(59766001)(77982001)(2656002)(81816001)(80976001)(81686001)(49866001)(47736001)(50986001)(90146001)(47976001)(56816005)(4396001)(85306002)(85852003)(83072002)(63696002)(54356001)(79102001)(76482001)(51856001)(66066001)(46102001)(53806001)(65816001)(80022001)(15975445006)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; CLIP:68.188.56.8; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "" 
Subject: Re: [TLS] Remarks on draft-popov-prohibiting-rc4-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 31 Dec 2013 17:09:04 -0000

Hi Eric,

> As a reality check, maybe we could get AGL, bsmith, Andrei, Wan-Teh etc. =
to weigh in on how small the RC4-
> only population would have to be before they are willing to turn off RC4 =
support in their products.

It would be hard to give a specific number or percentage of RC4-only server=
s that a browser vendor can ignore, because no browser vendor wants to be l=
ess compatible than the others. Also, while such a number or percentage cou=
ld practically be estimated by scanning the public Web, it would be difficu=
lt to get reliable data about all the private intranets out there.

Also, I believe the bulk of RC4 connections are negotiated because servers =
are configured to prefer RC4, not due to RC4 being the only common cipher s=
uite between the client and the server. IE 11 already somewhat alleviates t=
his problem by not offering RC4 on the initial connection attempt.

It is true that browser vendors, server operators, etc. are not required to=
 listen to the TLS WG. However, I also believe that deprecating weak cipher=
 suites (and adding new, secure ones) is due diligence for this WG, and tha=
t it sends a strong message to the vendors/operators.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Monday, December 30, 2013 8:12 AM
To: Yoav Nir
Cc: 
Subject: Re: [TLS] Remarks on draft-popov-prohibiting-rc4-01

On Mon, Dec 30, 2013 at 7:20 AM, Yoav Nir  wrote:
>
> On Dec 30, 2013, at 2:01 PM, Alyssa Rowan  wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> On 30/12/2013 09:50, Yoav Nir wrote:
>>> My only issue with this, is that clients and servers have to deal=20
>>> with the installed base, and the installed base includes IE6 running=20
>>> on XP, several older versions of Safari on outdated OSX, Firefox=20
>>> 3.6, and thousands of web servers running anything you can think of.
>>
>> Then the installed base *requires* an update: it can no longer=20
>> connect securely, and transport layer _security's_ job is to not be inse=
cure.
>
> Here's the thing. You, me, Yaron and Andrei can tell the world to=20
> upgrade in an RFC. The world is not required to listen to us. Browser=20
> makers are very wary of creating browsers that don't connect to what's=20
> out there. That's why they're willing to downgrade to SSLv3. Server=20
> vendors are also wary of locking out a bunch of browsers.

To elaborate on this point a bit, the critical factor here is clients and s=
ervers which support *only* RC4, since that's what causes bustage.
Historically, client vendors have resisted any change which breaks more tha=
n a small fraction of connections (and presumably server operators feel the=
 same way).

As a reality check, maybe we could get AGL, bsmith, Andrei, Wan-Teh etc. to=
 weigh in on how small the RC4-only population would have to be before they=
 are willing to turn off RC4 support in their products.

-Ekr

P.S. Ignoring general equilibrium effects simply having clients and servers=
 configured so that any pair which have a common cipher X better than
RC4 select X instead is still pretty good (assuming that the negotiation is=
 secured, and we have anti-rollback if necessary), since the impact would b=
e that X is selected where possible and RC4 where necessary.
Unless I misunderstand, RC4 is still superior to plaintext against the curr=
ent best results.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls