From nobody Sat Mar 1 08:28:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09501A0F52 for ; Sat, 1 Mar 2014 07:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 jabjZ7GTWOLU for ; Sat, 1 Mar 2014 07:02:22 -0800 (PST) Received: from vsp6.ballou.se (vsp6.ballou.se [91.189.40.85]) by ietfa.amsl.com (Postfix) with SMTP id B8C121A0F50 for ; Sat, 1 Mar 2014 07:02:20 -0800 (PST) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp6.ballou.se (Halon Mail Gateway) with ESMTP; Sat, 1 Mar 2014 16:02:07 +0100 (CET) Received: from [192.168.0.195] (c-a2c1e555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.193.162]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 8AF8F1E09F; Sat, 1 Mar 2014 16:02:13 +0100 (CET) Message-ID: <5311F652.4090804@streamsec.se> Date: Sat, 01 Mar 2014 16:01:38 +0100 From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Geoffrey Keating , Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C73723848D4@uxcn10-6.UoA.auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fWQiwE2LSSahR3jTLT1NVgQHU1c X-Mailman-Approved-At: Sat, 01 Mar 2014 08:28:29 -0800 Cc: "ietf-ssh@NetBSD.org" , "" Subject: Re: [TLS] I can has SHA-1 hashes for RFC 2409/3526 MODP groups? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list 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, 01 Mar 2014 15:02:24 -0000 On 2014-02-28 22:22, Geoffrey Keating wrote: > I'd encourage you to do the derivation again: compute > > 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 } > > and verify that it's prime. I don't think any special security > measures were taken during the creation of RFC 3526, you'd think by > now someone would have noticed if the 'primes' weren't prime or didn't > match the claimed polynomial, but if everyone thinks someone else has > checked... There is more. 1. The MODP primes are supposed to be safe primes (i.e. primes on the form p = 2q+1 where q is also prime). Furthermore, 2 will be a generator of the large sub group of order q, rather than of the entire multiplicative group of order 2q. 2. Pi might be calculated using the Bailey–Borwein–Plouffe formula. I calculated it for the first 2048 hexadecimal digits, which was a sufficiently good approximation for all of the MODP groups up to the 8192 bit one. 3. All of the MODP primes are on the form p = 2^n - 2^(n-64) + 2^64( [2^(n-130)pi] + k). The value k is supposed to be the least positive integer, such that p is a safe prime. This check is important, to rule out that any candidates have been deliberately skipped, because they lack some (hidden) property. I have generated the primes 1024, 2048, 3072, 4096, 6144 and 8192 from the formulae and verified that: a: The numbers match the numbers in the RFCs. b: The numbers are safe primes (using both Miller-Rabin tests and Lucas tests on q = (p-1)/2, and then the Pocklington Criterion on p). c: The small constant k is indeed the least positive integer such that the number is a safe prime. (Well, to be honest I am still running this test for the largest group, just make sure once more.) From nobody Sun Mar 2 10:38:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FAD1A09D6 for ; Sun, 2 Mar 2014 10:38:39 -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 5YwTacn2R2eZ for ; Sun, 2 Mar 2014 10:38:28 -0800 (PST) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C65861A09CF for ; Sun, 2 Mar 2014 10:38:28 -0800 (PST) Received: by mail-yh0-f43.google.com with SMTP id b6so2355334yha.16 for ; Sun, 02 Mar 2014 10:38: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=O1Ut7ZDKElA0Zt0/06rOMX9ILDHNt40tPvVOBR+BZcc=; b=C3J+xOJG2ahaYgzxIehfSZ9c1/7c9eJmWaAbe2tH2+1/vZ2zFP5EREKbxtRfSuu2lC ViAqnIW5FbaYAil8nR1MPtY59p/1daRBn4TNNuN9KoQtkSYc9Ge6sQZ95+wtRd5XhQfI abYuZsxQP4xRa0LMXlO3xWHGTGhORslP3omPQnQDt4IMcWJGfhgFfC8SNbl9k9DuNy/n 5WCQ6AVfQhbR33MFB8E7eqHKl8XeVZuWKsSU5yaASjwhn/Rw8ZPeuGzLpgliU3Kp/vV1 SfNAmv3GGzk4wGqLG8yKmfjI/WNUOlq0+lLIe/lOuTWvN/vk0E1HHPbGYgTWRKtTAW4C yG7g== MIME-Version: 1.0 X-Received: by 10.236.121.194 with SMTP id r42mr2531481yhh.82.1393785505993; Sun, 02 Mar 2014 10:38:25 -0800 (PST) Received: by 10.170.92.85 with HTTP; Sun, 2 Mar 2014 10:38:25 -0800 (PST) In-Reply-To: References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> Date: Sun, 2 Mar 2014 10:38:25 -0800 Message-ID: From: Watson Ladd To: Paul Lambert Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w__F0sBEOu5C9qaWIcOY7PNJQd0 Cc: "cfrg@irtf.org" , Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Sun, 02 Mar 2014 18:38:40 -0000 (Moving to TLS because that is where this draft is) On Sat, Mar 1, 2014 at 8:02 PM, Paul Lambert wrote: > > The curve25519 is NOT a good normative reference IETF protocols. > It=C2=B9s useful as an informative reference on the curve > Selection, but lacks clarity and completeness on > implementation details. Since when does a normative reference contain implementation details? IEEE 745 doesn't, RnRS doesn't, the ANSI C standard doesn't, POSIX doesn't, etc. This doesn't affect being able to judge compliance which is the normative function of a spec. If you want RFCs, try writing a NTP protocol implementation (that is, a client that keeps track of the current time accurately) without understanding PLL control theory. This isn't in the spec at all, but is completely necessary to get a functioning implementation. Furthermore, the Curve25519 paper describes a very clever implementation in great detail. > > One of the main reasons 25519 is popular is that a nicely optimized > open source library is available for some of the more > Useful curve functions. > > > On 3/1/14, 9:21 AM, "Paul Hoffman" wrote: > >>[[ Subject line changed to be relevant to the discussion ]] >> >>On Mar 1, 2014, at 4:16 AM, Robert Ransom wrote: >> >>> On 2/28/14, David McGrew wrote: >>>> I am wary of relying on the curve25519 paper as a normative reference. >>>> Perhaps your goal here is to provide an informational document (the >>>> draft that you mention above) that offers implementation guidance, >>>> instead of a normative reference? >>> >>> RFC 4492 (ECC ciphersuites for TLS) cites ANSI X9.62, IEEE 1363, and a >>> few documents labeled as =C5=92standards=C2=B9 by the corporations whic= h >>> authored them as normative references. It cannot be implemented >>> without the information in ANSI X9.62 and IEEE 1363. ANSI X9.62 is >>> available from ANSI for 100 USD; IEEE 1363 is available from ANSI for >>> 168 USD. >> >>I have been told by implementers that you can implement RFC 4492 just >>fine without those references, only with [SECG]. What information in the >>ANSI and IEEE spec do you feel is needed to implement 4492? > > We should be working here to document Edwards/Montgomery curves to > the same level of clarity as the SECG documents. Perhaps we > could be even more concise and complete - SECG left out > details of most optimizations. > > My favorite examples of clarity are: > http://www.nsa.gov/ia/_files/nist-routines.pdf > > http://www.nsa.gov/ia/_files/SuiteB_Implementer_G-113808.pdf > > Right now there is no equivalent documentation as the nist-routines.pdf > for Edwards/Montgomery curves. So your argument is that until such a document is written, the IETF should not approve any RFC containing such a curve because absent such a document, the specification is unclear? I disagree: the information you demand to be placed into the spec can be figured out in a few days of research in the library. There are numerous standard references on bignum arithmetic, and given this with the paper of Montgomery, there is nothing else that is needed to write an implementation that is correct. Sincerely, Watson Ladd > > Paul > >> >>> It is true that the author of the Curve25519 paper is neither a large >>> corporation nor an organization with =C2=B3Standards=C2=B2 in its name,= and did >>> not label Curve25519 as a =C5=92standard=C2=B9 in the paper's title. H= owever, >>> the Curve25519 scalar multiplication function specified in the paper >>> became a =C5=92standard=C2=B9, in the sense which IETF claims to use th= e word, >>> when software developers came to the rough consensus that it was a >>> good cryptographic primitive to use, and wrote and deployed running >>> code which implements it. >> >>That is not the sense which the IETF claims to use the word. >> >>> The Curve25519 paper is available for free >>> from the URL . >>> >>> What is your objection to using the Curve25519 paper as a normative >>> reference for the standard Curve25519 scalar multiplication function? >> >>The paper is at a URL; the contents of that URL can change any time. RFCs >>can sometimes make normative reference to URLs that seem very stable, and >>Dan's might or might not be. Dan has a history of poking at the IETF >>(sometimes for good reason), so it is quite believable that he might >>change the contents of that URL just to make a point. Having a more >>stable reference would clearly be better. >> >>--Paul Hoffman >>_______________________________________________ >>Cfrg mailing list >>Cfrg@irtf.org >>http://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Mar 2 14:46:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB81A1A099D; Sun, 2 Mar 2014 14:41:46 -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, 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 PhU97Xc67Erl; Sun, 2 Mar 2014 14:41:44 -0800 (PST) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id DF4FA1A07CA; Sun, 2 Mar 2014 14:41:44 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s22Mfdff025800; Sun, 2 Mar 2014 14:41:39 -0800 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0a-0016f401.pphosted.com with ESMTP id 1jbctpnjgt-284 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 02 Mar 2014 14:41:36 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Sun, 2 Mar 2014 14:41:05 -0800 From: Paul Lambert To: Watson Ladd Date: Sun, 2 Mar 2014 14:41:03 -0800 Thread-Topic: [Cfrg] Citing specs in specs Thread-Index: Ac82aH6lreVgle/bQLGnnXZhDmMtSg== Message-ID: References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-02_02:2014-02-28,2014-03-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403020154 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-MDT0j-w7ZmNNYrD3F9Ssh6JN08 X-Mailman-Approved-At: Sun, 02 Mar 2014 14:46:08 -0800 Cc: "cfrg@irtf.org" , Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Sun, 02 Mar 2014 22:41:47 -0000 DQoNCk9uIDMvMi8xNCwgMTA6MzggQU0sICJXYXRzb24gTGFkZCIgPHdhdHNvbmJsYWRkQGdtYWls LmNvbT4gd3JvdGU6DQoNCj4oTW92aW5nIHRvIFRMUyBiZWNhdXNlIHRoYXQgaXMgd2hlcmUgdGhp cyBkcmFmdCBpcykNCj4NCj5PbiBTYXQsIE1hciAxLCAyMDE0IGF0IDg6MDIgUE0sIFBhdWwgTGFt YmVydCA8cGF1bEBtYXJ2ZWxsLmNvbT4gd3JvdGU6DQo+Pg0KPj4gVGhlIGN1cnZlMjU1MTkgaXMg Tk9UIGEgZ29vZCBub3JtYXRpdmUgcmVmZXJlbmNlIElFVEYgcHJvdG9jb2xzLg0KPj4gSXTCuXMg dXNlZnVsIGFzIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSBvbiB0aGUgY3VydmUNCj4+IFNlbGVj dGlvbiwgYnV0IGxhY2tzIGNsYXJpdHkgYW5kIGNvbXBsZXRlbmVzcyBvbg0KPj4gaW1wbGVtZW50 YXRpb24gZGV0YWlscy4NCj4NCj5TaW5jZSB3aGVuIGRvZXMgYSBub3JtYXRpdmUgcmVmZXJlbmNl IGNvbnRhaW4gaW1wbGVtZW50YXRpb24gZGV0YWlscz8NCj4NCj5JRUVFIDc0NSBkb2Vzbid0LCBS blJTIGRvZXNuJ3QsIHRoZSBBTlNJIEMgc3RhbmRhcmQgZG9lc24ndCwgUE9TSVgNCj5kb2Vzbid0 LCBldGMuIFRoaXMgZG9lc24ndCBhZmZlY3QgYmVpbmcgYWJsZSB0byBqdWRnZSBjb21wbGlhbmNl IHdoaWNoDQo+aXMgdGhlIG5vcm1hdGl2ZSBmdW5jdGlvbiBvZiBhIHNwZWMuDQo+DQo+SWYgeW91 IHdhbnQgUkZDcywgdHJ5IHdyaXRpbmcgYSBOVFAgcHJvdG9jb2wgaW1wbGVtZW50YXRpb24gKHRo YXQgaXMsDQo+YSBjbGllbnQgdGhhdCBrZWVwcyB0cmFjayBvZiB0aGUgY3VycmVudCB0aW1lIGFj Y3VyYXRlbHkpIHdpdGhvdXQNCj51bmRlcnN0YW5kaW5nIFBMTCBjb250cm9sIHRoZW9yeS4gVGhp cyBpc24ndCBpbiB0aGUgc3BlYyBhdCBhbGwsIGJ1dA0KPmlzIGNvbXBsZXRlbHkgbmVjZXNzYXJ5 IHRvIGdldCBhIGZ1bmN0aW9uaW5nIGltcGxlbWVudGF0aW9uLg0KPg0KPkZ1cnRoZXJtb3JlLCB0 aGUgQ3VydmUyNTUxOSBwYXBlciBkZXNjcmliZXMgYSB2ZXJ5IGNsZXZlcg0KPmltcGxlbWVudGF0 aW9uIGluIGdyZWF0IGRldGFpbC4NCj4NCj4+DQo+PiBPbmUgb2YgdGhlIG1haW4gcmVhc29ucyAy NTUxOSBpcyBwb3B1bGFyIGlzIHRoYXQgYSBuaWNlbHkgb3B0aW1pemVkDQo+PiBvcGVuIHNvdXJj ZSBsaWJyYXJ5IGlzIGF2YWlsYWJsZSBmb3Igc29tZSBvZiB0aGUgbW9yZQ0KPj4gVXNlZnVsIGN1 cnZlIGZ1bmN0aW9ucy4NCj4+DQo+Pg0KPj4gT24gMy8xLzE0LCA5OjIxIEFNLCAiUGF1bCBIb2Zm bWFuIiA8cGF1bC5ob2ZmbWFuQHZwbmMub3JnPiB3cm90ZToNCj4+DQo+Pj5bWyBTdWJqZWN0IGxp bmUgY2hhbmdlZCB0byBiZSByZWxldmFudCB0byB0aGUgZGlzY3Vzc2lvbiBdXQ0KPj4+DQo+Pj5P biBNYXIgMSwgMjAxNCwgYXQgNDoxNiBBTSwgUm9iZXJ0IFJhbnNvbSA8cnJhbnNvbS44Nzc0QGdt YWlsLmNvbT4NCj4+Pndyb3RlOg0KPj4+DQo+Pj4+IE9uIDIvMjgvMTQsIERhdmlkIE1jR3JldyA8 bWNncmV3QGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+PiBJIGFtIHdhcnkgb2YgcmVseWluZyBvbiB0 aGUgY3VydmUyNTUxOSBwYXBlciBhcyBhIG5vcm1hdGl2ZQ0KPj4+Pj5yZWZlcmVuY2UuDQo+Pj4+ PiBQZXJoYXBzIHlvdXIgZ29hbCBoZXJlIGlzIHRvIHByb3ZpZGUgYW4gaW5mb3JtYXRpb25hbCBk b2N1bWVudCAodGhlDQo+Pj4+PiBkcmFmdCB0aGF0IHlvdSBtZW50aW9uIGFib3ZlKSB0aGF0IG9m ZmVycyBpbXBsZW1lbnRhdGlvbiBndWlkYW5jZSwNCj4+Pj4+IGluc3RlYWQgb2YgYSBub3JtYXRp dmUgcmVmZXJlbmNlPw0KPj4+Pg0KPj4+PiBSRkMgNDQ5MiAoRUNDIGNpcGhlcnN1aXRlcyBmb3Ig VExTKSBjaXRlcyBBTlNJIFg5LjYyLCBJRUVFIDEzNjMsIGFuZCBhDQo+Pj4+IGZldyBkb2N1bWVu dHMgbGFiZWxlZCBhcyDFknN0YW5kYXJkc8K5IGJ5IHRoZSBjb3Jwb3JhdGlvbnMgd2hpY2gNCj4+ Pj4gYXV0aG9yZWQgdGhlbSBhcyBub3JtYXRpdmUgcmVmZXJlbmNlcy4gIEl0IGNhbm5vdCBiZSBp bXBsZW1lbnRlZA0KPj4+PiB3aXRob3V0IHRoZSBpbmZvcm1hdGlvbiBpbiBBTlNJIFg5LjYyIGFu ZCBJRUVFIDEzNjMuICBBTlNJIFg5LjYyIGlzDQo+Pj4+IGF2YWlsYWJsZSBmcm9tIEFOU0kgZm9y IDEwMCBVU0Q7IElFRUUgMTM2MyBpcyBhdmFpbGFibGUgZnJvbSBBTlNJIGZvcg0KPj4+PiAxNjgg VVNELg0KPj4+DQo+Pj5JIGhhdmUgYmVlbiB0b2xkIGJ5IGltcGxlbWVudGVycyB0aGF0IHlvdSBj YW4gaW1wbGVtZW50IFJGQyA0NDkyIGp1c3QNCj4+PmZpbmUgd2l0aG91dCB0aG9zZSByZWZlcmVu Y2VzLCBvbmx5IHdpdGggW1NFQ0ddLiBXaGF0IGluZm9ybWF0aW9uIGluIHRoZQ0KPj4+QU5TSSBh bmQgSUVFRSBzcGVjIGRvIHlvdSBmZWVsIGlzIG5lZWRlZCB0byBpbXBsZW1lbnQgNDQ5Mj8NCj4+ DQo+PiBXZSBzaG91bGQgYmUgd29ya2luZyBoZXJlIHRvIGRvY3VtZW50IEVkd2FyZHMvTW9udGdv bWVyeSBjdXJ2ZXMgdG8NCj4+IHRoZSBzYW1lIGxldmVsIG9mIGNsYXJpdHkgYXMgdGhlIFNFQ0cg ZG9jdW1lbnRzLiAgUGVyaGFwcyB3ZQ0KPj4gY291bGQgYmUgZXZlbiBtb3JlIGNvbmNpc2UgYW5k IGNvbXBsZXRlIC0gU0VDRyBsZWZ0IG91dA0KPj4gZGV0YWlscyBvZiBtb3N0IG9wdGltaXphdGlv bnMuDQo+Pg0KPj4gTXkgZmF2b3JpdGUgZXhhbXBsZXMgb2YgY2xhcml0eSBhcmU6DQo+PiBodHRw Oi8vd3d3Lm5zYS5nb3YvaWEvX2ZpbGVzL25pc3Qtcm91dGluZXMucGRmDQo+Pg0KPj4gaHR0cDov L3d3dy5uc2EuZ292L2lhL19maWxlcy9TdWl0ZUJfSW1wbGVtZW50ZXJfRy0xMTM4MDgucGRmDQo+ Pg0KPj4gUmlnaHQgbm93IHRoZXJlIGlzIG5vIGVxdWl2YWxlbnQgZG9jdW1lbnRhdGlvbiBhcyB0 aGUgbmlzdC1yb3V0aW5lcy5wZGYNCj4+IGZvciBFZHdhcmRzL01vbnRnb21lcnkgY3VydmVzLg0K Pg0KPlNvIHlvdXIgYXJndW1lbnQgaXMgdGhhdCB1bnRpbCBzdWNoIGEgZG9jdW1lbnQgaXMgd3Jp dHRlbiwgdGhlIElFVEYNCj5zaG91bGQgbm90IGFwcHJvdmUgYW55IFJGQyBjb250YWluaW5nIHN1 Y2ggYSBjdXJ2ZSBiZWNhdXNlIGFic2VudCBzdWNoDQo+YSBkb2N1bWVudCwgdGhlIHNwZWNpZmlj YXRpb24gaXMgdW5jbGVhcj8NCg0KTm8gLSBJ4oCZbSBhc2tpbmcgdGhhdCBhbiBSRkMgYmUgd2Vs bCB3cml0dGVuIGFuZCBjb250YWluIGVub3VnaCBpbmZvcm1hdGlvbg0KdG8gaW1wbGVtZW50IHRo ZSBSRkMuDQoNCg0KUGF1bA0KDQoNCg0KPkkgZGlzYWdyZWU6IHRoZSBpbmZvcm1hdGlvbg0KPnlv dSBkZW1hbmQgdG8gYmUgcGxhY2VkIGludG8gdGhlIHNwZWMgY2FuIGJlIGZpZ3VyZWQgb3V0IGlu IGEgZmV3IGRheXMNCj5vZiByZXNlYXJjaCBpbiB0aGUgbGlicmFyeS4gVGhlcmUgYXJlIG51bWVy b3VzIHN0YW5kYXJkIHJlZmVyZW5jZXMgb24NCj5iaWdudW0gYXJpdGhtZXRpYywgYW5kIGdpdmVu IHRoaXMgd2l0aCB0aGUgcGFwZXIgb2YgTW9udGdvbWVyeSwgdGhlcmUNCj5pcyBub3RoaW5nIGVs c2UgdGhhdCBpcyBuZWVkZWQgdG8gd3JpdGUgYW4gaW1wbGVtZW50YXRpb24gdGhhdCBpcw0KPmNv cnJlY3QuDQo+DQo+U2luY2VyZWx5LA0KPldhdHNvbiBMYWRkDQo+Pg0KPj4gUGF1bA0KPj4NCj4+ Pg0KPj4+PiBJdCBpcyB0cnVlIHRoYXQgdGhlIGF1dGhvciBvZiB0aGUgQ3VydmUyNTUxOSBwYXBl ciBpcyBuZWl0aGVyIGEgbGFyZ2UNCj4+Pj4gY29ycG9yYXRpb24gbm9yIGFuIG9yZ2FuaXphdGlv biB3aXRoIMKzU3RhbmRhcmRzwrIgaW4gaXRzIG5hbWUsIGFuZCBkaWQNCj4+Pj4gbm90IGxhYmVs IEN1cnZlMjU1MTkgYXMgYSDFknN0YW5kYXJkwrkgaW4gdGhlIHBhcGVyJ3MgdGl0bGUuICBIb3dl dmVyLA0KPj4+PiB0aGUgQ3VydmUyNTUxOSBzY2FsYXIgbXVsdGlwbGljYXRpb24gZnVuY3Rpb24g c3BlY2lmaWVkIGluIHRoZSBwYXBlcg0KPj4+PiBiZWNhbWUgYSDFknN0YW5kYXJkwrksIGluIHRo ZSBzZW5zZSB3aGljaCBJRVRGIGNsYWltcyB0byB1c2UgdGhlIHdvcmQsDQo+Pj4+IHdoZW4gc29m dHdhcmUgZGV2ZWxvcGVycyBjYW1lIHRvIHRoZSByb3VnaCBjb25zZW5zdXMgdGhhdCBpdCB3YXMg YQ0KPj4+PiBnb29kIGNyeXB0b2dyYXBoaWMgcHJpbWl0aXZlIHRvIHVzZSwgYW5kIHdyb3RlIGFu ZCBkZXBsb3llZCBydW5uaW5nDQo+Pj4+IGNvZGUgd2hpY2ggaW1wbGVtZW50cyBpdC4NCj4+Pg0K Pj4+VGhhdCBpcyBub3QgdGhlIHNlbnNlIHdoaWNoIHRoZSBJRVRGIGNsYWltcyB0byB1c2UgdGhl IHdvcmQuDQo+Pj4NCj4+Pj4gVGhlIEN1cnZlMjU1MTkgcGFwZXIgaXMgYXZhaWxhYmxlIGZvciBm cmVlDQo+Pj4+IGZyb20gdGhlIFVSTCA8aHR0cDovL2NyLnlwLnRvL2VjZGgvY3VydmUyNTUxOS0y MDA2MDIwOS5wZGY+Lg0KPj4+Pg0KPj4+PiBXaGF0IGlzIHlvdXIgb2JqZWN0aW9uIHRvIHVzaW5n IHRoZSBDdXJ2ZTI1NTE5IHBhcGVyIGFzIGEgbm9ybWF0aXZlDQo+Pj4+IHJlZmVyZW5jZSBmb3Ig dGhlIHN0YW5kYXJkIEN1cnZlMjU1MTkgc2NhbGFyIG11bHRpcGxpY2F0aW9uIGZ1bmN0aW9uPw0K Pj4+DQo+Pj5UaGUgcGFwZXIgaXMgYXQgYSBVUkw7IHRoZSBjb250ZW50cyBvZiB0aGF0IFVSTCBj YW4gY2hhbmdlIGFueSB0aW1lLg0KPj4+UkZDcw0KPj4+Y2FuIHNvbWV0aW1lcyBtYWtlIG5vcm1h dGl2ZSByZWZlcmVuY2UgdG8gVVJMcyB0aGF0IHNlZW0gdmVyeSBzdGFibGUsDQo+Pj5hbmQNCj4+ PkRhbidzIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZS4gRGFuIGhhcyBhIGhpc3Rvcnkgb2YgcG9raW5n IGF0IHRoZSBJRVRGDQo+Pj4oc29tZXRpbWVzIGZvciBnb29kIHJlYXNvbiksIHNvIGl0IGlzIHF1 aXRlIGJlbGlldmFibGUgdGhhdCBoZSBtaWdodA0KPj4+Y2hhbmdlIHRoZSBjb250ZW50cyBvZiB0 aGF0IFVSTCBqdXN0IHRvIG1ha2UgYSBwb2ludC4gSGF2aW5nIGEgbW9yZQ0KPj4+c3RhYmxlIHJl ZmVyZW5jZSB3b3VsZCBjbGVhcmx5IGJlIGJldHRlci4NCj4+Pg0KPj4+LS1QYXVsIEhvZmZtYW4N Cj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5D ZnJnIG1haWxpbmcgbGlzdA0KPj4+Q2ZyZ0BpcnRmLm9yZw0KPj4+aHR0cDovL3d3dy5pcnRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NmcmcNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gQ2ZyZyBtYWlsaW5nIGxpc3QNCj4+IENmcmdAaXJ0 Zi5vcmcNCj4+IGh0dHA6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZnJnDQo+DQo+ DQo+DQo+LS0gDQo+IlRob3NlIHdobyB3b3VsZCBnaXZlIHVwIEVzc2VudGlhbCBMaWJlcnR5IHRv IHB1cmNoYXNlIGEgbGl0dGxlDQo+VGVtcG9yYXJ5IFNhZmV0eSBkZXNlcnZlIG5laXRoZXIgIExp YmVydHkgbm9yIFNhZmV0eS4iDQo+LS0gQmVuamFtaW4gRnJhbmtsaW4NCg0K From nobody Sun Mar 2 15:28:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A411A0B40 for ; Sun, 2 Mar 2014 15:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 S5RFuHJz7i9K for ; Sun, 2 Mar 2014 15:28:23 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id EA0321A0B23 for ; Sun, 2 Mar 2014 15:28:22 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2E3C047810; Sun, 2 Mar 2014 23:28:20 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 1B4D947802; Sun, 2 Mar 2014 23:28:20 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 066258004E; Sun, 2 Mar 2014 23:28:20 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.228]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Sun, 2 Mar 2014 18:28:19 -0500 From: "Salz, Rich" To: Paul Lambert , Watson Ladd Date: Sun, 2 Mar 2014 18:28:14 -0500 Thread-Topic: [Cfrg] Citing specs in specs Thread-Index: Ac82aH6lreVgle/bQLGnnXZhDmMtSgABhksg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kJtUf7rqRObR1mrtQIRKPLhj8CA Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Sun, 02 Mar 2014 23:28:25 -0000 PiBObyAtIEnigJltIGFza2luZyB0aGF0IGFuIFJGQyBiZSB3ZWxsIHdyaXR0ZW4gYW5kIGNvbnRh aW4gZW5vdWdoIGluZm9ybWF0aW9uIHRvIGltcGxlbWVudCB0aGUgUkZDLg0KDQpPa2F5LCB5b3Ug ZG9uJ3QgdGhpbmsgaXQncyBwb3NzaWJsZSB1c2luZywgYW1vbmcgb3RoZXIgaW5mb3JtYXRpb24s IHRoZSAyNTUxOSBwYXBlciBhcyBhbiBpbmZvcm1hdGlvbiBzb3VyY2UuICBPdGhlcnMgZG8gdGhp bmsgaXQgcG9zc2libGUsIGFuZCBoYXZlIG1hZGUgdGhlIHBvaW50IHRoYXQgdGhleSB0aGluayB0 aGlzIGlzIGFuIHVudXN1YWxseSBoaWdoIHJlcXVpcmVtZW50IGJlaW5nIGltcG9zZWQgaGVyZS4N Cg0KSGF2ZSBJIHN1bW1lZCB1cCB0aGUgYW5nbGUgYnJhY2tldHMgd2VsbCBlbm91Z2g/DQoNCi0t ICANClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcg0KQWthbWFpIFRlY2hub2xvZ3kNCkNhbWJy aWRnZSwgTUENCg== From nobody Sun Mar 2 15:56:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD261A0B5E for ; Sun, 2 Mar 2014 15:56:34 -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 DGAYlYgPD0Ul for ; Sun, 2 Mar 2014 15:56:32 -0800 (PST) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id 24D471A0B4C for ; Sun, 2 Mar 2014 15:56:32 -0800 (PST) Received: (qmail 548 invoked from network); 2 Mar 2014 23:56:30 -0000 Received: from unknown (HELO hyperelliptic.org) (131.155.71.33) by mace.cs.uic.edu with SMTP; 2 Mar 2014 23:56:30 -0000 Received: (qmail 15655 invoked by uid 1000); 2 Mar 2014 23:55:25 -0000 Date: Mon, 3 Mar 2014 00:55:25 +0100 From: Tanja Lange To: "Salz, Rich" Message-ID: <20140302235525.GV5925@cph.win.tue.nl> References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.11 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ykDjRo-RnR8DmH2A31_Ht8-iVMM Cc: Paul Lambert , "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Sun, 02 Mar 2014 23:56:34 -0000 Easy ways out: a) Refer to http://cr.yp.to/ecdh.html#curve25519-paper which lists all (2) versions of the paper. b) Refer to the Springer version -- it's open access per contract bewteen Springer and the IACR. http://link.springer.com/chapter/10.1007%2F11745853_14 From nobody Sun Mar 2 18:17:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77891A0BF4; Sun, 2 Mar 2014 18:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRA9FgwN11iz; Sun, 2 Mar 2014 18:17:19 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC151A0BE0; Sun, 2 Mar 2014 18:17:19 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.226.232.202]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s232GrJp009010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Mar 2014 18:17:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1393813028; bh=GfgXYNQh6mtkBgvG5aHzY7gPqVkLO7tjGabCP6thw0I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=s9MSs79mhcoISHjqg7Q3GcuDpS3OvFUppDCOkdhSLBG/F7yPqjzZdKTYtPp6ZW98d HU1PXl2o94sVIrJS/Azft8Q3uwmEiNqv2TswZ4+NKe/joyYTi2PfLGjDbyUc+dzFf/ RvEY+AhaWXCowqSEAyA9s5L5Pq92gpoeBm5v+Izo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1393813028; i=@elandsys.com; bh=GfgXYNQh6mtkBgvG5aHzY7gPqVkLO7tjGabCP6thw0I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jsjDO7+OnHYHeRiWKVQ3GRNWqOdT/7opBEQKYDxOyhsRPKLvsq5Tp4rKv5tLgwzF4 lWNWzBt0imiPwwccrwP+mYGfUVhb0EIVSUeV+EowocF7Haorbx8OmpGTbovhE8/Fdb 4JZ2XR6AIaoLVqQxoj3UUeWt2v8gAmYxBAyflY0s= Message-Id: <6.2.5.6.2.20140302175050.0b3b1558@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 02 Mar 2014 18:14:58 -0800 To: Paul Lambert , "Salz, Rich" , Watson Ladd From: S Moonesamy In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marve ll.com> References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pCs8dZggjc0-zIjYL9y44MU9vVo Cc: cfrg@irtf.org, tls@ietf.org Subject: Re: [TLS] [Cfrg] Citing specs in 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: Mon, 03 Mar 2014 02:17:22 -0000 Hi Paul, At 15:40 02-03-2014, Paul Lambert wrote: >Implementations are possible by using the readily available open source >implementation. This is a good thing, but it is also desirable >to have a unambiguous description of the algorithms that is not >a C code file. This is why we write RFCs... A Proposed Standard is about interoperability. It does not prescribe a method. The test is to determine whether the standard actually works is see whether there are different implementations which have been deployed. There is a Proposed Standard which contains the source code for a reference implementation. That was unusual. Please note that I currently have a draft referencing ED25519 [1]. Regards, S. Moonesamy 1. http://tools.ietf.org/html/draft-moonesamy-sshfp-ed25519-00 From nobody Sun Mar 2 18:51:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2D61A0C2B for ; Sun, 2 Mar 2014 18:51: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=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 e11fTT9otpMU for ; Sun, 2 Mar 2014 18:51:39 -0800 (PST) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 988221A0C1E for ; Sun, 2 Mar 2014 18:51:39 -0800 (PST) Received: by mail-yh0-f53.google.com with SMTP id v1so3053002yhn.12 for ; Sun, 02 Mar 2014 18:51: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; bh=yIEjPp4o/1N6ZwwnlEGBhwXdF/2nHNmgBf9g4AHftPk=; b=Cgllt7jgEyezzPQd798wP+eWJNuNP5BgReauTgATIjrKL1Ra6Yebt73UBCtQu0AoMo xiAHoMHh+aP71LL/SIcyD3Nko3+48D1+ys4s4rnPfvZhYhb4N51bVfHNfPw20fszxJ2s YxzB47PjfXUG3pGi4s/TQcw68NPmcX311puSDZopZwXC76uZS+wJyVBDflNAukuT1ope 6gINviBRveNDcNuM5tChdY/tJPhFWMwLQ14UJEOtVLHhzIMtsraoPJqj4xyjJA1Z8qPI cRJHkB8FGeYJIqQ6T2inZizny2gdd4/JQpuKNK+WQwf6e6dXSwpqK7e8X7vcR88W4+d6 mnLA== MIME-Version: 1.0 X-Received: by 10.236.142.198 with SMTP id i46mr4264936yhj.66.1393815096737; Sun, 02 Mar 2014 18:51:36 -0800 (PST) Received: by 10.170.92.85 with HTTP; Sun, 2 Mar 2014 18:51:36 -0800 (PST) In-Reply-To: <6.2.5.6.2.20140302175050.0b3b1558@elandnews.com> References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com> <6.2.5.6.2.20140302175050.0b3b1558@elandnews.com> Date: Sun, 2 Mar 2014 18:51:36 -0800 Message-ID: From: Watson Ladd To: S Moonesamy Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hKKhxg9gWPcjdt3FHOyndRo4L08 Cc: Paul Lambert , "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Mon, 03 Mar 2014 02:51:41 -0000 On Sun, Mar 2, 2014 at 6:14 PM, S Moonesamy wrote: > Hi Paul, > > At 15:40 02-03-2014, Paul Lambert wrote: >> >> Implementations are possible by using the readily available open source >> implementation. This is a good thing, but it is also desirable >> to have a unambiguous description of the algorithms that is not >> a C code file. This is why we write RFCs... > > > A Proposed Standard is about interoperability. It does not prescribe a > method. The test is to determine whether the standard actually works is see > whether there are different implementations which have been deployed. >From that perspective let me note that DJB's original assembly language implementation, Matthew Dempsky's 32 bit C implementation, and Adam Langley's 64 bit C implementations, were all independently developed from the paper. Furthermore, I've been able to do the same in a few hours, if not extremely concerned with speed. Sincerely, Watson Ladd > > There is a Proposed Standard which contains the source code for a reference > implementation. That was unusual. > > Please note that I currently have a draft referencing ED25519 [1]. > > Regards, > S. Moonesamy > > 1. http://tools.ietf.org/html/draft-moonesamy-sshfp-ed25519-00 -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Mar 2 22:52:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CD61A0D3D for ; Sun, 2 Mar 2014 22:52:45 -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, 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 2EPyYTm_jwbj for ; Sun, 2 Mar 2014 22:52:44 -0800 (PST) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 437E51A0CA3 for ; Sun, 2 Mar 2014 22:52:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 008394E5D43F; Sun, 2 Mar 2014 22:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-9KKeOzFwZl; Sun, 2 Mar 2014 22:52:31 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 6605E4E5D423; Sun, 2 Mar 2014 22:52:31 -0800 (PST) Received: from [10.0.23.100] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Sun, 02 Mar 2014 22:52:31 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Sun, 02 Mar 2014 22:52:31 -0800 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jon Callas In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com> Date: Sun, 2 Mar 2014 22:52:28 -0800 Message-Id: <7A2637AF-5A16-404B-B7A1-49FB17D5345A@callas.org> References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com> To: Paul Lambert X-Mailer: Apple Mail (2.1874) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4m64uscA0eMuo0eA9fUncu64cRQ Cc: "cfrg@irtf.org" , Jon Callas , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Mon, 03 Mar 2014 06:52:46 -0000 On Mar 2, 2014, at 3:40 PM, Paul Lambert wrote: > Implementations are possible by using the readily available open = source > implementation. This is a good thing, but it is also desirable > to have a unambiguous description of the algorithms that is not=20 > a C code file. This is why we write RFCs... It's hard to disagree with this, in a similar way that it's hard to = disagree with the idea of peace on earth, living at one with nature, = etc. But in practice, code needs to be in a computer language rather than = English and I've seen (and been involved with) a document that started = with rough consensus and running code, translated that into English, and = the English was (and is) devilishly hard to compile back into C. Portably implemented algorithms are hard to do in any computer language. = They're harder to do in words. I don't see how you're going to get an = unambiguous description of the language in anything but a computer = language. It doesn't have to be C, it could be Python, Ruby, or Algol-58 = (which I mention because it was originally designed as an algorithmic = description language). English is a suboptimal implementation language. Jon From nobody Mon Mar 3 01:01:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300841A0933; Sun, 2 Mar 2014 14:48:50 -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, 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 2sXVhM6d2Cow; Sun, 2 Mar 2014 14:48:48 -0800 (PST) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id BF3781A0932; Sun, 2 Mar 2014 14:48:48 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s22MmhCq032382; Sun, 2 Mar 2014 14:48:43 -0800 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0a-0016f401.pphosted.com with ESMTP id 1jbctpnm0j-25 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 02 Mar 2014 14:48:43 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Sun, 2 Mar 2014 14:48:39 -0800 From: Paul Lambert To: Paul Lambert , Watson Ladd Date: Sun, 2 Mar 2014 14:48:36 -0800 Thread-Topic: [Cfrg] Citing specs in specs Thread-Index: Ac82aYy/lMV42sZuSAaqtalpBBKyBw== Message-ID: References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-02_02:2014-02-28,2014-03-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403020156 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jqjUot-C6JeDfx6YELIj62mWmiU X-Mailman-Approved-At: Mon, 03 Mar 2014 01:01:37 -0800 Cc: "cfrg@irtf.org" , Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Sun, 02 Mar 2014 22:48:50 -0000 DQoNCj4+DQo+PlNvIHlvdXIgYXJndW1lbnQgaXMgdGhhdCB1bnRpbCBzdWNoIGEgZG9jdW1lbnQg aXMgd3JpdHRlbiwgdGhlIElFVEYNCj4+c2hvdWxkIG5vdCBhcHByb3ZlIGFueSBSRkMgY29udGFp bmluZyBzdWNoIGEgY3VydmUgYmVjYXVzZSBhYnNlbnQgc3VjaA0KPj5hIGRvY3VtZW50LCB0aGUg c3BlY2lmaWNhdGlvbiBpcyB1bmNsZWFyPw0KPg0KPk5vIC0gSeKAmW0gYXNraW5nIHRoYXQgYW4g UkZDIGJlIHdlbGwgd3JpdHRlbiBhbmQgY29udGFpbiBlbm91Z2ggaW5mb3JtYXRpb24NCj50byBp bXBsZW1lbnQgdGhlIFJGQy4NCg0KU2VlaW5nIG5vdyB0aGF0IHRoaXMgaXMgY3Jvc3MgcG9zdGVk IHRvIFRMU+KApiBsZXQgbWUgYmUgY2xlYXIuDQpUaGUgb251cyBpcyBvbnRoZSBDUkZHIHRvIHBy b2R1Y2UgYSB1c2VhYmxlIG5vcm1hdGl2ZSByZWZlcmVuY2UgdGhhdCBjYW4NCmJlIHVzZWQNCmJ5 IFRMUyBhbmQgb3RoZXIgSUVURiBwcm90b2NvbHMgZm9yIHVzaW5nIEVkd2FyZHMgYW5kIE1vbnRv Z29tZXJ5DQplbGxpcHRpYyBjdXJ2ZXMuDQoNClBhdWwNCg0KDQo+DQo+DQo+UGF1bA0KPg0KPg0K Pg0KPj5JIGRpc2FncmVlOiB0aGUgaW5mb3JtYXRpb24NCj4+eW91IGRlbWFuZCB0byBiZSBwbGFj ZWQgaW50byB0aGUgc3BlYyBjYW4gYmUgZmlndXJlZCBvdXQgaW4gYSBmZXcgZGF5cw0KPj5vZiBy ZXNlYXJjaCBpbiB0aGUgbGlicmFyeS4gVGhlcmUgYXJlIG51bWVyb3VzIHN0YW5kYXJkIHJlZmVy ZW5jZXMgb24NCj4+YmlnbnVtIGFyaXRobWV0aWMsIGFuZCBnaXZlbiB0aGlzIHdpdGggdGhlIHBh cGVyIG9mIE1vbnRnb21lcnksIHRoZXJlDQo+PmlzIG5vdGhpbmcgZWxzZSB0aGF0IGlzIG5lZWRl ZCB0byB3cml0ZSBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IGlzDQo+PmNvcnJlY3QuDQo+Pg0KPj5T aW5jZXJlbHksDQo+PldhdHNvbiBMYWRkDQo+Pj4NCj4+PiBQYXVsDQo+Pj4NCj4+Pj4NCj4+Pj4+ IEl0IGlzIHRydWUgdGhhdCB0aGUgYXV0aG9yIG9mIHRoZSBDdXJ2ZTI1NTE5IHBhcGVyIGlzIG5l aXRoZXIgYSBsYXJnZQ0KPj4+Pj4gY29ycG9yYXRpb24gbm9yIGFuIG9yZ2FuaXphdGlvbiB3aXRo IMKzU3RhbmRhcmRzwrIgaW4gaXRzIG5hbWUsIGFuZCBkaWQNCj4+Pj4+IG5vdCBsYWJlbCBDdXJ2 ZTI1NTE5IGFzIGEgxZJzdGFuZGFyZMK5IGluIHRoZSBwYXBlcidzIHRpdGxlLiAgSG93ZXZlciwN Cj4+Pj4+IHRoZSBDdXJ2ZTI1NTE5IHNjYWxhciBtdWx0aXBsaWNhdGlvbiBmdW5jdGlvbiBzcGVj aWZpZWQgaW4gdGhlIHBhcGVyDQo+Pj4+PiBiZWNhbWUgYSDFknN0YW5kYXJkwrksIGluIHRoZSBz ZW5zZSB3aGljaCBJRVRGIGNsYWltcyB0byB1c2UgdGhlIHdvcmQsDQo+Pj4+PiB3aGVuIHNvZnR3 YXJlIGRldmVsb3BlcnMgY2FtZSB0byB0aGUgcm91Z2ggY29uc2Vuc3VzIHRoYXQgaXQgd2FzIGEN Cj4+Pj4+IGdvb2QgY3J5cHRvZ3JhcGhpYyBwcmltaXRpdmUgdG8gdXNlLCBhbmQgd3JvdGUgYW5k IGRlcGxveWVkIHJ1bm5pbmcNCj4+Pj4+IGNvZGUgd2hpY2ggaW1wbGVtZW50cyBpdC4NCj4+Pj4N Cj4+Pj5UaGF0IGlzIG5vdCB0aGUgc2Vuc2Ugd2hpY2ggdGhlIElFVEYgY2xhaW1zIHRvIHVzZSB0 aGUgd29yZC4NCj4+Pj4NCj4+Pj4+IFRoZSBDdXJ2ZTI1NTE5IHBhcGVyIGlzIGF2YWlsYWJsZSBm b3IgZnJlZQ0KPj4+Pj4gZnJvbSB0aGUgVVJMIDxodHRwOi8vY3IueXAudG8vZWNkaC9jdXJ2ZTI1 NTE5LTIwMDYwMjA5LnBkZj4uDQo+Pj4+Pg0KPj4+Pj4gV2hhdCBpcyB5b3VyIG9iamVjdGlvbiB0 byB1c2luZyB0aGUgQ3VydmUyNTUxOSBwYXBlciBhcyBhIG5vcm1hdGl2ZQ0KPj4+Pj4gcmVmZXJl bmNlIGZvciB0aGUgc3RhbmRhcmQgQ3VydmUyNTUxOSBzY2FsYXIgbXVsdGlwbGljYXRpb24gZnVu Y3Rpb24/DQo+Pj4+DQo+Pj4+VGhlIHBhcGVyIGlzIGF0IGEgVVJMOyB0aGUgY29udGVudHMgb2Yg dGhhdCBVUkwgY2FuIGNoYW5nZSBhbnkgdGltZS4NCj4+Pj5SRkNzDQo+Pj4+Y2FuIHNvbWV0aW1l cyBtYWtlIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gVVJMcyB0aGF0IHNlZW0gdmVyeSBzdGFibGUs DQo+Pj4+YW5kDQo+Pj4+RGFuJ3MgbWlnaHQgb3IgbWlnaHQgbm90IGJlLiBEYW4gaGFzIGEgaGlz dG9yeSBvZiBwb2tpbmcgYXQgdGhlIElFVEYNCj4+Pj4oc29tZXRpbWVzIGZvciBnb29kIHJlYXNv biksIHNvIGl0IGlzIHF1aXRlIGJlbGlldmFibGUgdGhhdCBoZSBtaWdodA0KPj4+PmNoYW5nZSB0 aGUgY29udGVudHMgb2YgdGhhdCBVUkwganVzdCB0byBtYWtlIGEgcG9pbnQuIEhhdmluZyBhIG1v cmUNCj4+Pj5zdGFibGUgcmVmZXJlbmNlIHdvdWxkIGNsZWFybHkgYmUgYmV0dGVyLg0KPj4+Pg0K Pj4+Pi0tUGF1bCBIb2ZmbWFuDQo+Pj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+Pj5DZnJnIG1haWxpbmcgbGlzdA0KPj4+PkNmcmdAaXJ0Zi5vcmcN Cj4+Pj5odHRwOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vY2ZyZw0KPj4+DQo+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBDZnJn IG1haWxpbmcgbGlzdA0KPj4+IENmcmdAaXJ0Zi5vcmcNCj4+PiBodHRwOi8vd3d3LmlydGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2ZyZw0KPj4NCj4+DQo+Pg0KPj4tLSANCj4+IlRob3NlIHdobyB3 b3VsZCBnaXZlIHVwIEVzc2VudGlhbCBMaWJlcnR5IHRvIHB1cmNoYXNlIGEgbGl0dGxlDQo+PlRl bXBvcmFyeSBTYWZldHkgZGVzZXJ2ZSBuZWl0aGVyICBMaWJlcnR5IG5vciBTYWZldHkuIg0KPj4t LSBCZW5qYW1pbiBGcmFua2xpbg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Q2ZyZyBtYWlsaW5nIGxpc3QNCj5DZnJnQGlydGYub3JnDQo+aHR0 cDovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NmcmcNCg0K From nobody Mon Mar 3 01:01:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9541A09A6; Sun, 2 Mar 2014 15:40:54 -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, 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 893rITyLgq4V; Sun, 2 Mar 2014 15:40:53 -0800 (PST) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id 59F431A0B21; Sun, 2 Mar 2014 15:40:52 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s22Nekn9015807; Sun, 2 Mar 2014 15:40:46 -0800 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0a-0016f401.pphosted.com with ESMTP id 1jbctpnq6n-513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 02 Mar 2014 15:40:44 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::4561:8e1c:d59b:f770%17]) with mapi; Sun, 2 Mar 2014 15:40:31 -0800 From: Paul Lambert To: "Salz, Rich" , Watson Ladd Date: Sun, 2 Mar 2014 15:40:33 -0800 Thread-Topic: [Cfrg] Citing specs in specs Thread-Index: Ac82aH6lreVgle/bQLGnnXZhDmMtSgABhksgAABy9jA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com> References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-02_02:2014-02-28,2014-03-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403020165 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FxHMzilV0XL_o54PrnLtBLDND0Y X-Mailman-Approved-At: Mon, 03 Mar 2014 01:01:38 -0800 Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Sun, 02 Mar 2014 23:40:54 -0000 DQoNCl0tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KXUZyb206IFNhbHosIFJpY2ggW21haWx0 bzpyc2FsekBha2FtYWkuY29tXQ0KXQ0KXT4gTm8gLSBJ4oCZbSBhc2tpbmcgdGhhdCBhbiBSRkMg YmUgd2VsbCB3cml0dGVuIGFuZCBjb250YWluIGVub3VnaA0KXWluZm9ybWF0aW9uIHRvIGltcGxl bWVudCB0aGUgUkZDLg0KXQ0KXU9rYXksIHlvdSBkb24ndCB0aGluayBpdCdzIHBvc3NpYmxlIHVz aW5nLCBhbW9uZyBvdGhlciBpbmZvcm1hdGlvbiwgdGhlDQpdMjU1MTkgcGFwZXIgYXMgYW4gaW5m b3JtYXRpb24gc291cmNlLiAgT3RoZXJzIGRvIHRoaW5rIGl0IHBvc3NpYmxlLCBhbmQNCl1oYXZl IG1hZGUgdGhlIHBvaW50IHRoYXQgdGhleSB0aGluayB0aGlzIGlzIGFuIHVudXN1YWxseSBoaWdo DQpdcmVxdWlyZW1lbnQgYmVpbmcgaW1wb3NlZCBoZXJlLg0KDQpJbXBsZW1lbnRhdGlvbnMgYXJl IHBvc3NpYmxlIGJ5IHVzaW5nIHRoZSByZWFkaWx5IGF2YWlsYWJsZSBvcGVuIHNvdXJjZQ0KaW1w bGVtZW50YXRpb24uICBUaGlzIGlzIGEgZ29vZCB0aGluZywgYnV0IGl0IGlzIGFsc28gZGVzaXJh YmxlDQp0byBoYXZlIGEgdW5hbWJpZ3VvdXMgZGVzY3JpcHRpb24gb2YgdGhlIGFsZ29yaXRobXMg dGhhdCBpcyBub3QgDQphIEMgY29kZSBmaWxlLiAgVGhpcyBpcyB3aHkgd2Ugd3JpdGUgUkZDcy4u Lg0KDQpQYXVsIA0KDQoNCl0NCl1IYXZlIEkgc3VtbWVkIHVwIHRoZSBhbmdsZSBicmFja2V0cyB3 ZWxsIGVub3VnaD8NCl0NCl0tLQ0KXVByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcg0KXUFrYW1h aSBUZWNobm9sb2d5DQpdQ2FtYnJpZGdlLCBNQQ0K From nobody Mon Mar 3 01:47:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585571A0DAA; Mon, 3 Mar 2014 01:47: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyfAYR4oGutT; Mon, 3 Mar 2014 01:47:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBEF1A0DAE; Mon, 3 Mar 2014 01:47:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140303094755.4818.47992.idtracker@ietfa.amsl.com> Date: Mon, 03 Mar 2014 01:47:55 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rgZ2QUS2T_9-7ax014C6Y2T69XE Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-applayerprotoneg-05.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: Mon, 03 Mar 2014 09:47:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension Authors : Stephan Friedl Andrei Popov Adam Langley Emile Stephan Filename : draft-ietf-tls-applayerprotoneg-05.txt Pages : 9 Date : 2014-03-03 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 or UDP 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 connection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-applayerprotoneg-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 3 01:51:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490A61A0C0A for ; Mon, 3 Mar 2014 01:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.547, 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 erxZMJX-JVtS for ; Mon, 3 Mar 2014 01:51:47 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 980241A0DAF for ; Mon, 3 Mar 2014 01:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=978; q=dns/txt; s=iport; t=1393840305; x=1395049905; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=kDu+yPqx1bgRuBbWyts0L+8sm2tjukLOqHVjI/5rJyc=; b=K85OU92bmHfO0wGTwa3XqM7URK2CgfK11Lx0pWl44ekR7ZUVfrkVxpyR KIZ8YIRbZpozIV6bpftliQauMlwxz6cCi0mPMyVsresDOSiQO3jvoUmLG AUj2m3cKYhba9TXtBeYwmxC/qJxRzRaXk1ri+Kq67ka72GjXIqtlsxfaX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAhQFFOtJXHB/2dsb2JhbABagwaBEsBOgR4WdIInAQQ6UQEqFEImAQQbh3GcUK9vF44og1yBFASqZ4Mtgio X-IronPort-AV: E=Sophos;i="4.97,576,1389744000"; d="scan'208";a="24446703" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-4.cisco.com with ESMTP; 03 Mar 2014 09:51:44 +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 s239piLM005884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Mar 2014 09:51:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 03:51:44 -0600 From: "Stephan Friedl (sfriedl)" To: "tls@ietf.org" Thread-Topic: New Version draft-ietf-tls-applayerprotoneg-05 posted Thread-Index: Ac82xeaptmsIC2fTRwKYf5PkBt72YA== Date: Mon, 3 Mar 2014 09:51:44 +0000 Message-ID: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C23327967@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.96.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V56VXeloDxzRUq-ksVZ_MCtapjk Subject: [TLS] New Version draft-ietf-tls-applayerprotoneg-05 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2014 09:51:50 -0000 A revised version of draft-ietf-tls-applayerprotoneg, version 5 has been po= sted with the following changes from version 4: Replaced: 'TCP/IP port number' with 'TCP or UDP' Replaced: 'Implementations MUST ensure that an empty string is not included= and that no byte strings are truncated' with 'Empty strings MUST NOT be included and byte strings MUST NOT be= truncated' Replaced: 'field of the ("application_layer_protocol_negotiation(16)") exte= nsion SHALL be structured the same as described above for the client' with 'field of the ("application_layer_protocol_negotiation(16)") extension i= s structured the same as described above for the client' Struck: 'The "no_application_protocol" fatal alert is only defined for th= e "application_layer_protocol_negotiation" extension and MUST NOT be sent u= nless the server has received a ClientHello message containing this extensi= on.' Thanks, Stephan Friedl From nobody Mon Mar 3 02:01:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58991A0D56 for ; Mon, 3 Mar 2014 02:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Lweya82TVNRg for ; Mon, 3 Mar 2014 02:01:29 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 302BD1A0D69 for ; Mon, 3 Mar 2014 02:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=492; q=dns/txt; s=iport; t=1393840886; x=1395050486; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OC7wsCIAK3v3G3vecw8/9AQQwVti8P4/u4F/hzaAdvw=; b=kZEGc1EIH+MK+6xnhiqxhGSBvfHXtIc1TtvyUionVWkQudJ2OT7ngFSf Wx0Nq+mCiLhBAdfmTMU40AlYJVXMMvNdcPMYCn6b/vONYpAAZw94vDI/4 kTkqmY7AfFGsHcPXjoJUcGfYQ2jAbjWQ6tqQcCmmD7zDFTvx7hbwsfdpo c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0JAOZRFFOrRDoH/2dsb2JhbABagwY7Ua9wkGSBHhZ0giUBAQEEOEABEAsYCRYPCQMCAQIBRQYNAQcCh3QJBcwzF45ZB4Q4AQOJS45xgTKFGIthg0se X-IronPort-AV: E=Sophos;i="4.97,576,1389744000"; d="scan'208";a="107497112" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 03 Mar 2014 10:01:26 +0000 Received: from [10.0.2.15] (sjc-vpn5-1074.cisco.com [10.21.92.50]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s23A1Ov6027491; Mon, 3 Mar 2014 10:01:25 GMT Message-ID: <531452F4.7060303@cisco.com> Date: Mon, 03 Mar 2014 05:01:24 -0500 From: David McGrew User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9 MIME-Version: 1.0 To: Tanja Lange References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> <20140302235525.GV5925@cph.win.tue.nl> In-Reply-To: <20140302235525.GV5925@cph.win.tue.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w9WJWHWD2fRevpKYWW39FDR1P4w Cc: Paul Lambert , "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Mon, 03 Mar 2014 10:01:33 -0000 On 03/02/2014 06:55 PM, Tanja Lange wrote: > Easy ways out: > a) Refer to > http://cr.yp.to/ecdh.html#curve25519-paper > which lists all (2) versions of the paper. > b) Refer to the Springer version -- it's open access per contract > bewteen Springer and the IACR. > http://link.springer.com/chapter/10.1007%2F11745853_14 > Thanks, Tanja, the PKC2006 reference (including the link to the Springer PDF) would definitely be the best way to reference this work. David From nobody Mon Mar 3 02:17:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB251A0E44 for ; Mon, 3 Mar 2014 02:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 ip_AN7IJI1Cs for ; Mon, 3 Mar 2014 02:17:02 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE631A0E3E for ; Mon, 3 Mar 2014 02:17:01 -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 s23AGwQL014295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 3 Mar 2014 05:16:59 -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 s23AGuUx009442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 3 Mar 2014 05:16:58 -0500 Message-ID: <1393841816.10260.17.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "tls@ietf.org" Date: Mon, 03 Mar 2014 11:16:56 +0100 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LjjnLUUCgcC7tnQm02xOw9u_Q_U Subject: [TLS] New Version for draft-mavrogiannopoulos-chacha-tls-02.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, 03 Mar 2014 10:17:03 -0000 A new version of draft-mavrogiannopoulos-chacha-tls was uploaded at: http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-02 This version modifies the previous draft to use the variant of Chacha described in the CFRG draft (with 96-bit nonces): http://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305-01 regards, Nikos From nobody Mon Mar 3 07:21:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E431A004A for ; Mon, 3 Mar 2014 07:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF2mtcMvPZ2R for ; Mon, 3 Mar 2014 07:21:01 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id 47F971A0133 for ; Mon, 3 Mar 2014 07:21:00 -0800 (PST) X-IronPort-AV: E=Sophos; i="4.97,577,1389740400"; d="scan'208,217"; a="61079042" Received: from dhcp-a4d4.meeting.ietf.org ([31.133.164.212]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 03 Mar 2014 16:20:56 +0100 From: Karthikeyan Bhargavan Content-Type: multipart/alternative; boundary="Apple-Mail=_E1B0B893-1C31-4973-B05B-7AF81CC5604F" Message-Id: Date: Mon, 3 Mar 2014 15:20:55 +0000 To: tls@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/e_jsCEATXnkPHJ7CCK5YOZoL9IQ Subject: [TLS] MITM Attacks on Client Authentication after 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, 03 Mar 2014 15:21:04 -0000 --Apple-Mail=_E1B0B893-1C31-4973-B05B-7AF81CC5604F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We are going to present some new man-in-the-middle attacks on TLS applications in Tuesday=92s working group meeting. These attacks were found as part of our research on trying to prove cryptographic security for a TLS implementation [1]. We presenting some of the materials here to kick-start some discussion and get early comments on our proposed countermeasure. Some people on the list already know of these attacks but this is the first public disclosure. More details are at https://secure-resumption.com [2] Scenario =3D=3D=3D=3D=3D=3D Consider a client C that normally authenticates to a server S using a client certificate. If C uses the same certificate to authenticate to a malicious server M, then we show that M can use C=92s certificate to authenticate its own connection to S. The attack relies on the combination of an initial RSA or DHE handshake, followed by session resumption on a new connection, followed by a client-authenticated renegotiation. During the first two handshakes, C has a connection to M and M has a connection to S. During the third handshake, M is able to authenticate as C to S and as S to C. This server-based man-in-the-middle attack should normally have been prevented by the Renegotiation Indication (RI) extension [3] but by injecting session resumption between the two full handshakes, we are able to bypass the renegotiation countermeasure. Triple Handshake Attack =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I=92ll briefly summarise the attack below for an initial RSA key exchange. The webpage [2] has diagrams that will be easier to follow, describes more attack variants, and provides some disclosure status. The attack proceeds in three steps: Step 1. (Initial Handshakes C-M, M-S) - C connects to M and M connects to S, both handshakes use RSA. - M forwards C=92s and S=92s client hellos to each other. - M receives an encrypted PMS from C and reencrypts it towards S. - Both handshakes complete with new sessions and record keys. Both sessions have the same master secret, random nonces, and session = id. (M knows the master secret and record keys since it participated in = both handshakes) Step 2. (Session Resumption C-M, M-S) - C resumes its session with M on a new connection. =20 - M resumes its session with S on a new connection. - M forwards all the abbreviated handshake messages unchanged between C = and S. - Note that the RI extensions on both handshakes are empty,=20 since it is the first handshake on the connection - Both handshakes complete with new record keys (and reuse old sessions) Both connections have the same record keys and handshake logs (verify = data) (M still knows the record keys and can send messages in either = direction.) Step 3. (Renegotiation C-M-S) - S requests M for renegotiation with client certificate.=20 M requests C for renegotiation with client certificate. - M forwards all renegotiation messages unchanged between C and S=20 - Note that since the handshake logs in the preceding handshake were the = same,=20 the RI extensions on both handshakes will be the same. - Both handshakes complete with new mutually-authenticated sessions and = record keys. C now thinks it is connected to S and S thinks it is connected to C. (M does not know the new record keys but its previous messages to S on = the same connection=20 may be treated as authenticated by C.) At the end of Step 3, S has an incoming connection on which it initially received data from an anonymous client (M) and later received data from an authenticated client (C). This breaks the intended guarantees of the RI extension. Countermeasures=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D During Step 3, C has a connection on which it first received M=92s certificate and later S=92s certificate. If C refuses to accept this change of server identity, then it can prevent Step 3 of the attack. Indeed, we recommend mainstream web browsers and HTTPS libraries should systematically forbid the change of server identities during renegotiation. However, already at the end of Step 2, a number of connection and session parameters, such as the tls-unique channel binding for the two connections are the same. So any application-level mechanism that relies on the TLS master secret [4] or channel bindings [5] or exports TLS keying material [6] is vulnerable to a similar man-in-the-middle attack. We argue that the core vulnerability here is that the TLS master secret is not bound to enough elements of the TLS session. We propose a new TLS extension that binds the master secret to the hash of the all relevant handshake messages in the initial handshake. The proposed draft is available at: http://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt The key idea is that each full handshake is associated with a session hash, computed as =09 session_hash =3D Hash(handshake_messages)=20 =09 where handshake_messages consist of all messages up to and including the ClientKeyExchange. The extended master secret computation enabled by the extension is then computed as =09 master_secret =3D PRF(pre_master_secret,=20 "extended master secret",=20 session_hash) [0..47];=20 =09 We=92ve implemented this extension in OpenSSL without much difficulty. Changing the master secret derivation may seem radical, but we believe it is the main way to counter future attacks that may rely on the session synchronization (step 1) that we exploit here. An alternative countermeasure would be an extension (along the lines of [3]) that includes the session hash as defined above in the ClientHello and ServerHello messages of the abbreviated handshake. This would provide an explicit link between the resumption handshake and its original full handshake, and hence prevent the renegotiation attack described above. We welcome comments and suggestions. -Karthik Bhargavan, Antoine Delignat-Lavaud, and Alfredo Pironti [1] http://mitls.org [2] https://secure-resumption.com [3] RFC5746: Transport Layer Security Renegotiation Indication Extension [4] The Compound Authentication Binding Problem = (draft-puthenkulam-eap-binding-04) [5] RFC5929: Channel Bindings for TLS [6] RFC5705: Keying Material Exporters for Transport Layer Security= --Apple-Mail=_E1B0B893-1C31-4973-B05B-7AF81CC5604F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 We are = going to present some new man-in-the-middle attacks on = TLS
applications in Tuesday=92s working group meeting. These attacks = were
found as part of our research on trying to prove = cryptographic
security for a TLS implementation [1].  We = presenting some of the
materials here to kick-start some discussion = and get early comments on
our proposed countermeasure. Some people on = the list already know of
these attacks but this is the first public = disclosure.

More details are at https://secure-resumption.com&n= bsp;[2]

Scenario
=3D=3D=3D=3D=3D=3D
Consider a client C = that normally authenticates to a server S using a
client certificate. =  If C uses the same certificate to authenticate to
a malicious = server M, then we show that M can use C=92s certificate = to
authenticate its own connection to S.

The attack relies on = the combination of an initial RSA or DHE
handshake, followed by = session resumption on a new connection,
followed by a = client-authenticated renegotiation. During the first two
handshakes, = C has a connection to M and M has a connection to
S. During the third = handshake, M is able to authenticate as C to S and
as S to = C.

This server-based man-in-the-middle attack should normally = have been
prevented by the Renegotiation Indication (RI) extension = [3] but by
injecting session resumption between the two full = handshakes, we are
able to bypass the renegotiation = countermeasure.

Triple Handshake = Attack
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I=92ll = briefly summarise the attack below for an initial RSA key
exchange. =  The webpage [2] has diagrams that will be easier to = follow,
describes more attack variants, and provides some disclosure = status.

The attack proceeds in three steps:

Step 1. = (Initial Handshakes C-M, M-S)
- C connects to M and M connects to S, = both handshakes use RSA.
- M forwards C=92s and S=92s client hellos = to each other.
- M receives an encrypted PMS from C and reencrypts it = towards S.
- Both handshakes complete with new sessions and record = keys.
  Both sessions have the same master secret, random = nonces, and session id.
  (M knows the master secret and = record keys since it participated in both handshakes)

Step 2. = (Session Resumption C-M, M-S)
- C resumes its session with M on a new = connection. =      
- M resumes its session with S = on a new connection.
- M forwards all the abbreviated handshake = messages unchanged between C and S.
- Note that the RI extensions on = both handshakes are empty, 
  since it is the first = handshake on the connection
- Both handshakes complete with new = record keys (and reuse old sessions)
  Both connections = have the same record keys and handshake logs (verify = data)
  (M still knows the record keys and can send = messages in either direction.)

Step 3. (Renegotiation C-M-S)
- = S requests M for renegotiation with client = certificate. 
  M requests C for renegotiation with = client certificate.
- M forwards all renegotiation messages unchanged = between C and S 
- Note that since the handshake logs in the = preceding handshake were the same, 
  the RI = extensions on both handshakes will be the same.
- Both handshakes = complete with new mutually-authenticated sessions and record = keys.
  C now thinks it is connected to S and S thinks it = is connected to C.
  (M does not know the new record keys = but its previous messages to S on the same = connection 
  may be treated as authenticated by = C.)

At the end of Step 3, S has an incoming connection on which = it
initially received data from an anonymous client (M) and = later
received data from an authenticated client (C). This breaks = the
intended guarantees of the RI = extension.

Countermeasures 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
During Step 3, C has a connection on which it first received = M=92s
certificate and later S=92s certificate. If C refuses to accept = this
change of server identity, then it can prevent Step 3 of = the
attack. Indeed, we recommend mainstream web browsers and = HTTPS
libraries should systematically forbid the change of server = identities
during renegotiation.

However, already at the end = of Step 2, a number of connection and
session parameters, such as the = tls-unique channel binding for the two
connections are the same. So = any application-level mechanism that
relies on the TLS master secret = [4] or channel bindings [5] or exports
TLS keying material [6] is = vulnerable to a similar man-in-the-middle
attack.

We argue = that the core vulnerability here is that the TLS master
secret is not = bound to enough elements of the TLS session. We propose
a new TLS = extension that binds the master secret to the hash of the
all = relevant handshake messages in the initial handshake.

The = proposed draft is available at:
 http://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt

The key idea is that each full handshake is associated with a = session
hash, computed as

session_hash =3D = Hash(handshake_messages) 

where handshake_messages = consist of all messages up to and including
the ClientKeyExchange. =  The extended master secret computation enabled
by the extension = is then computed as

master_secret =3D = PRF(pre_master_secret, 
       =             &n= bsp;           &nbs= p;        "extended master = secret", 
         &n= bsp;           &nbs= p;            =        session_hash) = [0..47]; 

We=92ve implemented this extension in OpenSSL without = much difficulty.
Changing the master secret derivation may seem = radical, but we believe
it is the main way to counter future attacks = that may rely on the
session synchronization (step 1) that we exploit = here.

An alternative countermeasure would be an extension (along = the lines
of [3]) that includes the session hash as defined above in = the
ClientHello and ServerHello messages of the = abbreviated
handshake. This would provide an explicit link between = the resumption
handshake and its original full handshake, and hence = prevent the
renegotiation attack described above.

We welcome = comments and suggestions.
-Karthik Bhargavan, Antoine = Delignat-Lavaud, and Alfredo Pironti

[1] http://mitls.org
[2] https://secure-resumption.com[3] RFC5746: Transport Layer Security Renegotiation Indication = Extension
[4] The Compound Authentication Binding Problem = (draft-puthenkulam-eap-binding-04)
[5] RFC5929: Channel Bindings for = TLS
[6] RFC5705: Keying Material Exporters for Transport Layer = Security= --Apple-Mail=_E1B0B893-1C31-4973-B05B-7AF81CC5604F-- From nobody Mon Mar 3 08:30:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0108F1A010B for ; Mon, 3 Mar 2014 08:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, 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 SX3-4X6zrLPd for ; Mon, 3 Mar 2014 08:30:24 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 01B491A00BB for ; Mon, 3 Mar 2014 08:30:23 -0800 (PST) Received: from mail145-co9-R.bigfish.com (10.236.132.229) by CO9EHSOBE021.bigfish.com (10.236.130.84) with Microsoft SMTP Server id 14.1.225.22; Mon, 3 Mar 2014 16:30:21 +0000 Received: from mail145-co9 (localhost [127.0.0.1]) by mail145-co9-R.bigfish.com (Postfix) with ESMTP id DB084480453; Mon, 3 Mar 2014 16:30:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.149; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0311HT001.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: PS-2(zzbb2dI98dIzz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h177df4h17326ah8275bh8275dh1de097h186068h1954cbhz2fh109h2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail145-co9: 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=AM2PRD0311HT001.eurprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019001)(6009001)(428001)(479174003)(199002)(189002)(24454002)(74706001)(74876001)(93516002)(74366001)(76786001)(94946001)(53806001)(65816001)(56776001)(77982001)(66066001)(31966008)(47446002)(74482001)(54316002)(93136001)(81342001)(86362001)(81542001)(80022001)(54356001)(36756003)(95666003)(92726001)(63696002)(76482001)(15202345003)(76796001)(80976001)(59766001)(74662001)(46102001)(16601075003)(83506001)(51856001)(83322001)(74502001)(90146001)(69226001)(85852003)(85306002)(56816005)(87936001)(15975445006)(47736001)(19580405001)(83072002)(81816001)(4396001)(95416001)(81686001)(19580395003)(94316002)(92566001)(2656002)(49866001)(15395725003)(47976001)(50986001)(87266001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB031; H:DBXPR03MB383.eurprd03.prod.outlook.com; CLIP:157.140.35.7; FPR:F41CF0F4.A4FA5312.BDD75D8B.E99191.206C4; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail145-co9 (localhost.localdomain [127.0.0.1]) by mail145-co9 (MessageSwitch) id 1393864218402238_18255; Mon, 3 Mar 2014 16:30:18 +0000 (UTC) Received: from CO9EHSMHS003.bigfish.com (unknown [10.236.132.245]) by mail145-co9.bigfish.com (Postfix) with ESMTP id 5E162360095; Mon, 3 Mar 2014 16:30:18 +0000 (UTC) Received: from AM2PRD0311HT001.eurprd03.prod.outlook.com (157.56.249.149) by CO9EHSMHS003.bigfish.com (10.236.130.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 3 Mar 2014 16:30:16 +0000 Received: from DBXPR03MB031.eurprd03.prod.outlook.com (10.242.145.147) by AM2PRD0311HT001.eurprd03.prod.outlook.com (10.255.162.36) with Microsoft SMTP Server (TLS) id 14.16.423.0; Mon, 3 Mar 2014 16:30:05 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB031.eurprd03.prod.outlook.com (10.242.145.147) with Microsoft SMTP Server (TLS) id 15.0.888.9; Mon, 3 Mar 2014 16:30:04 +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.0888.003; Mon, 3 Mar 2014 16:30:04 +0000 From: "Paterson, Kenny" To: Karthikeyan Bhargavan , "tls@ietf.org" Thread-Topic: [TLS] MITM Attacks on Client Authentication after Resumption Thread-Index: AQHPNvQ8UESJIvYGkUWBabB9Ec6CVprPjbaA Date: Mon, 3 Mar 2014 16:30:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [157.140.35.7] x-forefront-prvs: 0139052FDB Content-Type: text/plain; charset="iso-8859-1" Content-ID: <914E2E79A6F07542AE1D49A2D75F9DB2@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% Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ootpu87EllshNcioDYcWqPABsHY Subject: Re: [TLS] MITM Attacks on Client Authentication after 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, 03 Mar 2014 16:30:28 -0000 Hi Great work, and much kudos to Karthik and the team for finding this attack, documenting it, and engaging in its responsible disclosure. I think it's important to highlight one issue in the high-level description given by Karthik, below. Although the 3-step attack is described as a "server-based man-in-the-middle attack", the attacking server M, at the very end of the attack after step 3, does NOT end up knowing the keys being used by the attacked client and server, C and S. Rather, an application running at C might end up using TLS-protected data that was supplied by M in step 2 of the attack as if it came from S (or vice-versa). This is a comparable attack to the original renegotiation attack of Ray&Dispensa and Rex. So the text in Karthik's message: > During the third handshake, M is able to authenticate as C to S and as S >to C=20 is not correct, as far as I can see - for the 3rd step of the attack, it seems that M just passes messages backwards and forwards and ends up NOT knowing the keys shared by C and S. Any authentication protocol is vulnerable to a "message passing" attack of this type in which the adversary simply acts as a wire, and it's not considered an attack on such protocols. What matters here is how a server application running at S interprets data that may have been sent under TLS protection in the first 2 steps in the attack: it may assume it came from C when in fact it came from M. The more accurate description from Karthik's text is this: > Step 3. (Renegotiation C-M-S) > ... > Both handshakes complete with new mutually-authenticated sessions and >record keys. > C now thinks it is connected to S and S thinks it is connected to C. > (M does not know the new record keys but its previous messages to S on >the same connection > may be treated as authenticated by C.) Indeed, it's correct that C *is* connected to S and S *is* connected to C after step 3! (not just that they "think" they are so-connected). Cheers Kenny =20 On 03/03/2014 15:20, "Karthikeyan Bhargavan" wrote: We are going to present some new man-in-the-middle attacks on TLS applications in Tuesday=B9s working group meeting. These attacks were found as part of our research on trying to prove cryptographic security for a TLS implementation [1]. We presenting some of the materials here to kick-start some discussion and get early comments on our proposed countermeasure. Some people on the list already know of these attacks but this is the first public disclosure. More details are at https://secure-resumption.com [2] Scenario =3D=3D=3D=3D=3D=3D Consider a client C that normally authenticates to a server S using a client certificate. If C uses the same certificate to authenticate to a malicious server M, then we show that M can use C=B9s certificate to authenticate its own connection to S. The attack relies on the combination of an initial RSA or DHE handshake, followed by session resumption on a new connection, followed by a client-authenticated renegotiation. During the first two handshakes, C has a connection to M and M has a connection to S. During the third handshake, M is able to authenticate as C to S and as S to C. This server-based man-in-the-middle attack should normally have been prevented by the Renegotiation Indication (RI) extension [3] but by injecting session resumption between the two full handshakes, we are able to bypass the renegotiation countermeasure. Triple Handshake Attack =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I=B9ll briefly summarise the attack below for an initial RSA key exchange. The webpage [2] has diagrams that will be easier to follow, describes more attack variants, and provides some disclosure status. The attack proceeds in three steps: Step 1. (Initial Handshakes C-M, M-S) - C connects to M and M connects to S, both handshakes use RSA. - M forwards C=B9s and S=B9s client hellos to each other. - M receives an encrypted PMS from C and reencrypts it towards S. - Both handshakes complete with new sessions and record keys. Both sessions have the same master secret, random nonces, and session id. (M knows the master secret and record keys since it participated in both handshakes) Step 2. (Session Resumption C-M, M-S) - C resumes its session with M on a new connection. - M resumes its session with S on a new connection. - M forwards all the abbreviated handshake messages unchanged between C and S. - Note that the RI extensions on both handshakes are empty, since it is the first handshake on the connection - Both handshakes complete with new record keys (and reuse old sessions) Both connections have the same record keys and handshake logs (verify data) (M still knows the record keys and can send messages in either direction.) Step 3. (Renegotiation C-M-S) - S requests M for renegotiation with client certificate. M requests C for renegotiation with client certificate. - M forwards all renegotiation messages unchanged between C and S - Note that since the handshake logs in the preceding handshake were the same,=20 the RI extensions on both handshakes will be the same. - Both handshakes complete with new mutually-authenticated sessions and record keys. C now thinks it is connected to S and S thinks it is connected to C. (M does not know the new record keys but its previous messages to S on the same connection may be treated as authenticated by C.) At the end of Step 3, S has an incoming connection on which it initially received data from an anonymous client (M) and later received data from an authenticated client (C). This breaks the intended guarantees of the RI extension. Countermeasures=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D During Step 3, C has a connection on which it first received M=B9s certificate and later S=B9s certificate. If C refuses to accept this change of server identity, then it can prevent Step 3 of the attack. Indeed, we recommend mainstream web browsers and HTTPS libraries should systematically forbid the change of server identities during renegotiation. However, already at the end of Step 2, a number of connection and session parameters, such as the tls-unique channel binding for the two connections are the same. So any application-level mechanism that relies on the TLS master secret [4] or channel bindings [5] or exports TLS keying material [6] is vulnerable to a similar man-in-the-middle attack. We argue that the core vulnerability here is that the TLS master secret is not bound to enough elements of the TLS session. We propose a new TLS extension that binds the master secret to the hash of the all relevant handshake messages in the initial handshake. The proposed draft is available at: http://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt The key idea is that each full handshake is associated with a session hash, computed as session_hash =3D Hash(handshake_messages) where handshake_messages consist of all messages up to and including the ClientKeyExchange. The extended master secret computation enabled by the extension is then computed as master_secret =3D PRF(pre_master_secret, "extended master secret", session_hash) [0..47]; We=B9ve implemented this extension in OpenSSL without much difficulty. Changing the master secret derivation may seem radical, but we believe it is the main way to counter future attacks that may rely on the session synchronization (step 1) that we exploit here. An alternative countermeasure would be an extension (along the lines of [3]) that includes the session hash as defined above in the ClientHello and ServerHello messages of the abbreviated handshake. This would provide an explicit link between the resumption handshake and its original full handshake, and hence prevent the renegotiation attack described above. We welcome comments and suggestions. -Karthik Bhargavan, Antoine Delignat-Lavaud, and Alfredo Pironti [1] http://mitls.org [2] https://secure-resumption.com [3] RFC5746: Transport Layer Security Renegotiation Indication Extension [4] The Compound Authentication Binding Problem (draft-puthenkulam-eap-binding-04) [5] RFC5929: Channel Bindings for TLS [6] RFC5705: Keying Material Exporters for Transport Layer Security From nobody Mon Mar 3 08:36:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E355F1A01F0 for ; Mon, 3 Mar 2014 08:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o1NAiRRAZoh for ; Mon, 3 Mar 2014 08:36:55 -0800 (PST) Received: from claranet-outbound-smtp02.uk.clara.net (claranet-outbound-smtp02.uk.clara.net [195.8.89.35]) by ietfa.amsl.com (Postfix) with ESMTP id C6E521A01D9 for ; Mon, 3 Mar 2014 08:36:55 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:23794 helo=[192.168.7.9]) by relay12.mail.eu.clara.net (relay.clara.net [81.171.239.32]:10465) with esmtpa (authdaemon_plain:drh) id 1WKVrC-0002qR-99 for tls@ietf.org (return-path ); Mon, 03 Mar 2014 16:36:46 +0000 Message-ID: <5314AF9B.8000402@drh-consultancy.co.uk> Date: Mon, 03 Mar 2014 16:36:43 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/43vMgEIwwhSwQ3b8tyf-HZ5_D60 Subject: Re: [TLS] MITM Attacks on Client Authentication after 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, 03 Mar 2014 16:36:58 -0000 On 03/03/2014 15:20, Karthikeyan Bhargavan wrote: > We are going to present some new man-in-the-middle attacks on TLS > applications in Tuesdays working group meeting. These attacks were > found as part of our research on trying to prove cryptographic > security for a TLS implementation [1]. We presenting some of the > materials here to kick-start some discussion and get early comments on > our proposed countermeasure. Some people on the list already know of > these attacks but this is the first public disclosure. > > More details are at https://secure-resumption.com [2] > I'll just repeat an observation I made at the time. I'm assuming this is still valid. If the client verifies certificate chains whenever they are presented[1] the attacker needs a certificate and corresponding private key the client trusts, typically from a public CA. If not the client will typically reject the certificate and abort the handshake immediately. Assuming due diligence by the CA anyone detecting the attack will know the identity of the attacker or more accurately the identity presented to and checked by the CA. If the client checks the hostname against the certificate whenever a certificate is presented[2] then additionally the attacker needs a certificate with the same hostname as the attacked server. Steve. 1. As opposed to letting everything through and verifying chains after the handshake is complete. Not something I'd consider wise... 2. This isn't always the case. Some applications check the hostname only after the handshake has completed. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nobody Mon Mar 3 08:47:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6741A0281 for ; Mon, 3 Mar 2014 08:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGog82W1x8XP for ; Mon, 3 Mar 2014 08:47:02 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id 817F71A0255 for ; Mon, 3 Mar 2014 08:47:01 -0800 (PST) X-IronPort-AV: E=Sophos; i="4.97,578,1389740400"; d="scan'208,217"; a="61093697" Received: from dhcp-a4d4.meeting.ietf.org ([31.133.164.212]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 03 Mar 2014 17:46:55 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_31EB049C-8A55-4BAD-A92E-E4E650223D4E" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Mon, 3 Mar 2014 16:46:51 +0000 Message-Id: References: To: "Paterson, Kenny" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EsQK8jxoRaZcKl0jq1gX8zFz1RA Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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, 03 Mar 2014 16:47:06 -0000 --Apple-Mail=_31EB049C-8A55-4BAD-A92E-E4E650223D4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Rather, an application running at C might end up using TLS-protected = data > that was supplied by M in step 2 of the attack as if it came from S = (or > vice-versa). This is a comparable attack to the original renegotiation > attack of Ray&Dispensa and Rex. Yes, indeed, the impact of our renegotiation attack is comparable to the = 2009 renegotiation attacks. In fact, the setup of our attack is closer to Rex=92s version than Ray=92s= version: http://www.ietf.org/mail-archive/web/tls/current/msg03928.html > as far as I can see - for the 3rd step of the attack, it > seems that M just passes messages backwards and forwards and ends up = NOT > knowing the keys shared by C and S. Any authentication protocol is > vulnerable to a "message passing" attack of this type in which the > adversary simply acts as a wire, and it's not considered an attack on = such > protocols. I would note that the renegotiation handshake we are speaking about is = not exactly a standalone authentication protocol. It is the second = handshake on a connection, with different client or server identity than = the first handshake. This leaves room for confusion: should an = implementation associate the connection to the first set of principals = or the second?=20 > Indeed, it's correct that C *is* connected to S and S *is* connected = to C > after step 3! (not just that they "think" they are so-connected). Kenny, you seem to suggest that only the second should be considered. = Common web browsers and HTTPS libraries only consider the first. It is = interesting to try and understand which is the right answer here. -Karthik >=20 > What matters here is how a server application running at S interprets = data > that may have been sent under TLS protection in the first 2 steps in = the > attack: it may assume it came from C when in fact it came from M. >=20 > The more accurate description from Karthik's text is this: >=20 >> Step 3. (Renegotiation C-M-S) >=20 >> ... >> Both handshakes complete with new mutually-authenticated sessions and >> record keys. >> C now thinks it is connected to S and S thinks it is connected to C. >> (M does not know the new record keys but its previous messages to S = on >> the same connection >> may be treated as authenticated by C.) >=20 >=20 > Indeed, it's correct that C *is* connected to S and S *is* connected = to C > after step 3! (not just that they "think" they are so-connected). >=20 > Cheers >=20 > Kenny >=20 >=20 > On 03/03/2014 15:20, "Karthikeyan Bhargavan" > wrote: >=20 > We are going to present some new man-in-the-middle attacks on TLS > applications in Tuesday=B9s working group meeting. These attacks were > found as part of our research on trying to prove cryptographic > security for a TLS implementation [1]. We presenting some of the > materials here to kick-start some discussion and get early comments on > our proposed countermeasure. Some people on the list already know of > these attacks but this is the first public disclosure. >=20 > More details are at https://secure-resumption.com > [2] >=20 > Scenario > =3D=3D=3D=3D=3D=3D > Consider a client C that normally authenticates to a server S using a > client certificate. If C uses the same certificate to authenticate to > a malicious server M, then we show that M can use C=B9s certificate to > authenticate its own connection to S. >=20 > The attack relies on the combination of an initial RSA or DHE > handshake, followed by session resumption on a new connection, > followed by a client-authenticated renegotiation. During the first two > handshakes, C has a connection to M and M has a connection to > S. During the third handshake, M is able to authenticate as C to S and > as S to C. >=20 > This server-based man-in-the-middle attack should normally have been > prevented by the Renegotiation Indication (RI) extension [3] but by > injecting session resumption between the two full handshakes, we are > able to bypass the renegotiation countermeasure. >=20 > Triple Handshake Attack > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I=B9ll briefly summarise the attack below for an initial RSA key > exchange. The webpage [2] has diagrams that will be easier to follow, > describes more attack variants, and provides some disclosure status. >=20 > The attack proceeds in three steps: >=20 > Step 1. (Initial Handshakes C-M, M-S) > - C connects to M and M connects to S, both handshakes use RSA. > - M forwards C=B9s and S=B9s client hellos to each other. > - M receives an encrypted PMS from C and reencrypts it towards S. > - Both handshakes complete with new sessions and record keys. > Both sessions have the same master secret, random nonces, and session = id. > (M knows the master secret and record keys since it participated in = both > handshakes) >=20 > Step 2. (Session Resumption C-M, M-S) > - C resumes its session with M on a new connection. > - M resumes its session with S on a new connection. > - M forwards all the abbreviated handshake messages unchanged between = C > and S. > - Note that the RI extensions on both handshakes are empty, > since it is the first handshake on the connection > - Both handshakes complete with new record keys (and reuse old = sessions) > Both connections have the same record keys and handshake logs (verify > data) > (M still knows the record keys and can send messages in either > direction.) >=20 > Step 3. (Renegotiation C-M-S) > - S requests M for renegotiation with client certificate. > M requests C for renegotiation with client certificate. > - M forwards all renegotiation messages unchanged between C and S > - Note that since the handshake logs in the preceding handshake were = the > same,=20 > the RI extensions on both handshakes will be the same. > - Both handshakes complete with new mutually-authenticated sessions = and > record keys. > C now thinks it is connected to S and S thinks it is connected to C. > (M does not know the new record keys but its previous messages to S = on > the same connection > may be treated as authenticated by C.) >=20 > At the end of Step 3, S has an incoming connection on which it > initially received data from an anonymous client (M) and later > received data from an authenticated client (C). This breaks the > intended guarantees of the RI extension. >=20 > Countermeasures=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > During Step 3, C has a connection on which it first received M=B9s > certificate and later S=B9s certificate. If C refuses to accept this > change of server identity, then it can prevent Step 3 of the > attack. Indeed, we recommend mainstream web browsers and HTTPS > libraries should systematically forbid the change of server identities > during renegotiation. >=20 > However, already at the end of Step 2, a number of connection and > session parameters, such as the tls-unique channel binding for the two > connections are the same. So any application-level mechanism that > relies on the TLS master secret [4] or channel bindings [5] or exports > TLS keying material [6] is vulnerable to a similar man-in-the-middle > attack. >=20 > We argue that the core vulnerability here is that the TLS master > secret is not bound to enough elements of the TLS session. We propose > a new TLS extension that binds the master secret to the hash of the > all relevant handshake messages in the initial handshake. >=20 > The proposed draft is available at: > http://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt >=20 > The key idea is that each full handshake is associated with a session > hash, computed as >=20 > session_hash =3D Hash(handshake_messages) >=20 > where handshake_messages consist of all messages up to and including > the ClientKeyExchange. The extended master secret computation enabled > by the extension is then computed as >=20 > master_secret =3D PRF(pre_master_secret, > "extended master secret", > session_hash) [0..47]; >=20 > We=B9ve implemented this extension in OpenSSL without much difficulty. > Changing the master secret derivation may seem radical, but we believe > it is the main way to counter future attacks that may rely on the > session synchronization (step 1) that we exploit here. >=20 > An alternative countermeasure would be an extension (along the lines > of [3]) that includes the session hash as defined above in the > ClientHello and ServerHello messages of the abbreviated > handshake. This would provide an explicit link between the resumption > handshake and its original full handshake, and hence prevent the > renegotiation attack described above. >=20 > We welcome comments and suggestions. > -Karthik Bhargavan, Antoine Delignat-Lavaud, and Alfredo Pironti >=20 > [1] http://mitls.org > [2] https://secure-resumption.com > [3] RFC5746: Transport Layer Security Renegotiation Indication = Extension > [4] The Compound Authentication Binding Problem > (draft-puthenkulam-eap-binding-04) > [5] RFC5929: Channel Bindings for TLS > [6] RFC5705: Keying Material Exporters for Transport Layer Security >=20 --Apple-Mail=_31EB049C-8A55-4BAD-A92E-E4E650223D4E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Rather, = an application running at C might end up using TLS-protected = data
that was supplied by M in step 2 of the attack as if it came = from S (or
vice-versa). This is a comparable attack to the original = renegotiation
attack of Ray&Dispensa and = Rex.

Yes, indeed, the impact of our = renegotiation attack is comparable to the 2009 renegotiation = attacks.
In fact, the setup of our attack is closer to Rex=92s = version than Ray=92s version:

as far as I can see - for the 3rd = step of the attack, it
seems that M just passes messages backwards = and forwards and ends up NOT
knowing the keys shared by C and S. Any = authentication protocol is
vulnerable to a "message passing" attack = of this type in which the
adversary simply acts as a wire, and it's = not considered an attack on = such
protocols.

I would note that = the renegotiation handshake we are speaking about is not exactly a = standalone authentication protocol. It is the second handshake on a = connection, with different client or server identity than the first = handshake. This leaves room for confusion: should an implementation = associate the connection to the first set of principals or the = second? 

Indeed, = it's correct that C *is* connected to S and S *is* connected to = C
after step 3! (not just that they "think" they are = so-connected).

Kenny, you seem to = suggest that only the second should be considered. Common web browsers = and HTTPS libraries only consider the first. It is interesting to try = and understand which is the right answer = here.

-Karthik



What matters here is how a server application = running at S interprets data
that may have been sent under TLS = protection in the first 2 steps in the
attack: it may assume it came = from C when in fact it came from M.

The more accurate description = from Karthik's text is this:

Step 3. = (Renegotiation C-M-S)

...
Both handshakes complete with new = mutually-authenticated sessions and
record keys.
C now thinks it = is connected to S and S thinks it is connected to C.
(M does not know = the new record keys but its previous messages to S on
the same = connection
may be treated as authenticated by = C.)


Indeed, it's correct that C *is* connected = to S and S *is* connected to C
after step 3! (not just that they = "think" they are so-connected).

Cheers

Kenny


On = 03/03/2014 15:20, "Karthikeyan Bhargavan"
<karthikeyan.bhargavan@inria= .fr> wrote:

We are going to present some new = man-in-the-middle attacks on TLS
applications in Tuesday=B9s working = group meeting. These attacks were
found as part of our research on = trying to prove cryptographic
security for a TLS implementation [1]. =  We presenting some of the
materials here to kick-start some = discussion and get early comments on
our proposed countermeasure. = Some people on the list already know of
these attacks but this is the = first public disclosure.

More details are at https://secure-resumption.com<https://secure-resumption.com/= > [2]

Scenario
=3D=3D=3D=3D=3D=3D
Consider a client C = that normally authenticates to a server S using a
client certificate. =  If C uses the same certificate to authenticate to
a malicious = server M, then we show that M can use C=B9s certificate = to
authenticate its own connection to S.

The attack relies on = the combination of an initial RSA or DHE
handshake, followed by = session resumption on a new connection,
followed by a = client-authenticated renegotiation. During the first two
handshakes, = C has a connection to M and M has a connection to
S. During the third = handshake, M is able to authenticate as C to S and
as S to = C.

This server-based man-in-the-middle attack should normally = have been
prevented by the Renegotiation Indication (RI) extension = [3] but by
injecting session resumption between the two full = handshakes, we are
able to bypass the renegotiation = countermeasure.

Triple Handshake = Attack
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I=B9ll = briefly summarise the attack below for an initial RSA key
exchange. =  The webpage [2] has diagrams that will be easier to = follow,
describes more attack variants, and provides some disclosure = status.

The attack proceeds in three steps:

Step 1. = (Initial Handshakes C-M, M-S)
- C connects to M and M connects to S, = both handshakes use RSA.
- M forwards C=B9s and S=B9s client hellos = to each other.
- M receives an encrypted PMS from C and reencrypts it = towards S.
- Both handshakes complete with new sessions and record = keys.
 Both sessions have the same master secret, random = nonces, and session id.
 (M knows the master secret and record = keys since it participated in both
handshakes)

Step 2. = (Session Resumption C-M, M-S)
- C resumes its session with M on a new = connection.
- M resumes its session with S on a new connection.
- = M forwards all the abbreviated handshake messages unchanged between = C
and S.
- Note that the RI extensions on both handshakes are = empty,
 since it is the first handshake on the connection
- = Both handshakes complete with new record keys (and reuse old = sessions)
 Both connections have the same record keys and = handshake logs (verify
data)
 (M still knows the record keys = and can send messages in either
direction.)

Step 3. = (Renegotiation C-M-S)
- S requests M for renegotiation with client = certificate.
 M requests C for renegotiation with client = certificate.
- M forwards all renegotiation messages unchanged = between C and S
- Note that since the handshake logs in the preceding = handshake were the
same,
 the RI extensions on both = handshakes will be the same.
- Both handshakes complete with new = mutually-authenticated sessions and
record keys.
 C now = thinks it is connected to S and S thinks it is connected to C.
=  (M does not know the new record keys but its previous messages to = S on
the same connection
 may be treated as authenticated by = C.)

At the end of Step 3, S has an incoming connection on which = it
initially received data from an anonymous client (M) and = later
received data from an authenticated client (C). This breaks = the
intended guarantees of the RI extension.

Countermeasures =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
During Step 3, C has a = connection on which it first received M=B9s
certificate and later S=B9s= certificate. If C refuses to accept this
change of server identity, = then it can prevent Step 3 of the
attack. Indeed, we recommend = mainstream web browsers and HTTPS
libraries should systematically = forbid the change of server identities
during = renegotiation.

However, already at the end of Step 2, a number of = connection and
session parameters, such as the tls-unique channel = binding for the two
connections are the same. So any = application-level mechanism that
relies on the TLS master secret [4] = or channel bindings [5] or exports
TLS keying material [6] is = vulnerable to a similar man-in-the-middle
attack.

We argue = that the core vulnerability here is that the TLS master
secret is not = bound to enough elements of the TLS session. We propose
a new TLS = extension that binds the master secret to the hash of the
all = relevant handshake messages in the initial handshake.

The = proposed draft is available at:
http://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt

The key idea is that each full handshake is associated with a = session
hash, computed as

session_hash =3D = Hash(handshake_messages)

where handshake_messages consist of all = messages up to and including
the ClientKeyExchange.  The = extended master secret computation enabled
by the extension is then = computed as

master_secret =3D PRF(pre_master_secret,
=             &n= bsp;           &nbs= p;            =   "extended master secret",
=             &n= bsp;           &nbs= p;            =    session_hash) [0..47];

We=B9ve implemented this = extension in OpenSSL without much difficulty.
Changing the master = secret derivation may seem radical, but we believe
it is the main way = to counter future attacks that may rely on the
session = synchronization (step 1) that we exploit here.

An alternative = countermeasure would be an extension (along the lines
of [3]) that = includes the session hash as defined above in the
ClientHello and = ServerHello messages of the abbreviated
handshake. This would provide = an explicit link between the resumption
handshake and its original = full handshake, and hence prevent the
renegotiation attack described = above.

We welcome comments and suggestions.
-Karthik = Bhargavan, Antoine Delignat-Lavaud, and Alfredo Pironti

[1] http://mitls.org <http://mitls.org/>
[2] https://secure-resumption.com = <https://secure-resumption.com/= >
[3] RFC5746: Transport Layer Security Renegotiation Indication = Extension
[4] The Compound Authentication Binding = Problem
(draft-puthenkulam-eap-binding-04)
[5] RFC5929: Channel = Bindings for TLS
[6] RFC5705: Keying Material Exporters for Transport = Layer Security


= --Apple-Mail=_31EB049C-8A55-4BAD-A92E-E4E650223D4E-- From nobody Mon Mar 3 08:47:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95C51A028C for ; Mon, 3 Mar 2014 08:47: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, 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 R9t_WStY77rH for ; Mon, 3 Mar 2014 08:47:29 -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 2079C1A0284 for ; Mon, 3 Mar 2014 08:47:28 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id l18so3504211wgh.21 for ; Mon, 03 Mar 2014 08:47: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=dSKPwrc8XEHHAmc++e6jFRbBECsStBAV/GJODRQb3S8=; b=ASr1xjgJzHl5l4vqHohHj0e8IL1UHTmtmrA/Js9wWQyv/0hdDGKV6BB2CsIjbxRRij R4EICM7jlFcPUGKrEO1DumYTMqy4NBZ5txlbI/zIsdLwDQvlZRIWDOsuY6IdnhHJ6Jwx 6FYRuXsR2vjPgt+Acd6iPg4hjvC2H5dOeU1nFeslRc5B1cvwHoDAkcR7WsWGyuCaWgYX r01CMLsbGDiLMqoYHfRVfFakZb0HotZzCnXFYzUwuTGpNz72oIrWh6Yq761cNTEUFiJ6 t1pxDUomE8TQnOsU0GrnYUTE0VtggZam7hIIANWyRtBhbG6IO9DAXBUiFuGtJC4ZvL7/ 7fEA== MIME-Version: 1.0 X-Received: by 10.194.78.180 with SMTP id c20mr8779473wjx.57.1393865240761; Mon, 03 Mar 2014 08:47:20 -0800 (PST) Received: by 10.227.10.196 with HTTP; Mon, 3 Mar 2014 08:47:20 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Mar 2014 08:47:20 -0800 Message-ID: From: Martin Thomson To: Karthikeyan Bhargavan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MocQ-Y3TUH4T9kUnWTxh8FS9fps Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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, 03 Mar 2014 16:47:31 -0000 On 3 March 2014 07:20, Karthikeyan Bhargavan wrote: > master_secret = PRF(pre_master_secret, > "extended master secret", > session_hash) [0..47]; This would prevent the use of false start, would it not? From nobody Mon Mar 3 08:54:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDCE1A0229 for ; Mon, 3 Mar 2014 08:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, 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 xYQAp4iOo0JJ for ; Mon, 3 Mar 2014 08:54:54 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id DFD5F1A02A4 for ; Mon, 3 Mar 2014 08:54:53 -0800 (PST) Received: from mail144-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Mon, 3 Mar 2014 16:54:50 +0000 Received: from mail144-tx2 (localhost [127.0.0.1]) by mail144-tx2-R.bigfish.com (Postfix) with ESMTP id BC83314015E; Mon, 3 Mar 2014 16:54:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.149; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0311HT001.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zzbb2dI98dIc89bh1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL177df4h17326ah8275bh8275dh1de097h186068h1954cbhz2fh109h2a8h839h942he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail144-tx2: 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=AM2PRD0311HT001.eurprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019001)(6009001)(428001)(51704005)(479174003)(189002)(199002)(24454002)(66066001)(87266001)(94946001)(2656002)(16601075003)(77982001)(76796001)(95416001)(69226001)(4396001)(85306002)(59766001)(94316002)(50986001)(47976001)(74366001)(15395725003)(74876001)(76786001)(63696002)(74706001)(81542001)(81342001)(92566001)(56776001)(80976001)(65816001)(36756003)(47736001)(83072002)(19580405001)(83322001)(19580395003)(93136001)(93516002)(15202345003)(85852003)(87936001)(86362001)(81686001)(51856001)(92726001)(15975445006)(54356001)(46102001)(56816005)(90146001)(31966008)(74502001)(83506001)(54316002)(80022001)(53806001)(49866001)(95666003)(81816001)(76482001)(74662001)(47446002)(74482001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB030; H:DBXPR03MB383.eurprd03.prod.outlook.com; CLIP:157.140.35.7; FPR:F40FF1F4.A2FA5392.BDF75D8B.E99191.206FD; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail144-tx2 (localhost.localdomain [127.0.0.1]) by mail144-tx2 (MessageSwitch) id 1393865689301250_10785; Mon, 3 Mar 2014 16:54:49 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.238]) by mail144-tx2.bigfish.com (Postfix) with ESMTP id 8FE2B2C0065; Mon, 3 Mar 2014 16:54:48 +0000 (UTC) Received: from AM2PRD0311HT001.eurprd03.prod.outlook.com (157.56.249.149) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 3 Mar 2014 16:54:45 +0000 Received: from DBXPR03MB030.eurprd03.prod.outlook.com (10.242.145.146) by AM2PRD0311HT001.eurprd03.prod.outlook.com (10.255.162.36) with Microsoft SMTP Server (TLS) id 14.16.423.0; Mon, 3 Mar 2014 16:54:43 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB030.eurprd03.prod.outlook.com (10.242.145.146) with Microsoft SMTP Server (TLS) id 15.0.888.9; Mon, 3 Mar 2014 16:54: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.0888.003; Mon, 3 Mar 2014 16:54:42 +0000 From: "Paterson, Kenny" To: Karthikeyan Bhargavan Thread-Topic: [TLS] MITM Attacks on Client Authentication after Resumption Thread-Index: AQHPNvQ8UESJIvYGkUWBabB9Ec6CVprPjbaAgAAEu4CAAAIoAA== Date: Mon, 3 Mar 2014 16:54:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [157.140.35.7] x-forefront-prvs: 0139052FDB Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/tls/p7bpvLZpeDmEaKSApQdtAd0xWR4 Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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, 03 Mar 2014 16:54:58 -0000 S2FydGhpaywNCg0KU29ycnksIEkgd2FzIGp1c3QgdHJ5aW5nIHRvIGNsYXJpZnkgdGhlIGltcGFj dCBvZiB5b3VyIGF0dGFjayBmb3INCm5vbi1leHBlcnRzIC0gdGhlIHN1Z2dlc3Rpb24gdGhhdCBp dCBpcyBhIE1JVE0gYXR0YWNrIG1pZ2h0IG1ha2Ugc29tZQ0KcmVhZGVycyB0aGluayB0aGF0IE0g ZW5kcyB1cCBrbm93aW5nIHRoZSBrZXlzIGF0IHRoZSBlbmQgb2YgdGhlIGF0dGFjay4NCg0KSSB0 b3RhbGx5IGFncmVlIHRoYXQgaXQncyB1bmNsZWFyIGFzIHRvIHdoYXQgImJpbmRpbmdzIiBzaG91 bGQgYmUgYXNzdW1lZA0KYnkgdGhlIHByb3RvY29sIHBhcnRpY2lwYW50cyBhdCB0aGUgZW5kIG9m IHN0ZXAgMy4NCg0KQXMgSSBzYWlkLCBhbmQgSSdsbCByZWl0ZXJhdGUgLSBncmVhdCB3b3JrIGd1 eXMhDQoNCkNoZWVycw0KDQpLZW5ueQ0KDQpPbiAwMy8wMy8yMDE0IDE2OjQ2LCAiS2FydGhpa2V5 YW4gQmhhcmdhdmFuIg0KPGthcnRoaWtleWFuLmJoYXJnYXZhbkBpbnJpYS5mcj4gd3JvdGU6DQoN Cj4NCj4NCj4NCj5SYXRoZXIsIGFuIGFwcGxpY2F0aW9uIHJ1bm5pbmcgYXQgQyBtaWdodCBlbmQg dXAgdXNpbmcgVExTLXByb3RlY3RlZCBkYXRhDQo+dGhhdCB3YXMgc3VwcGxpZWQgYnkgTSBpbiBz dGVwIDIgb2YgdGhlIGF0dGFjayBhcyBpZiBpdCBjYW1lIGZyb20gUyAob3INCj52aWNlLXZlcnNh KS4gVGhpcyBpcyBhIGNvbXBhcmFibGUgYXR0YWNrIHRvIHRoZSBvcmlnaW5hbCByZW5lZ290aWF0 aW9uDQo+YXR0YWNrIG9mIFJheSZEaXNwZW5zYSBhbmQgUmV4Lg0KPg0KPg0KPg0KPg0KPlllcywg aW5kZWVkLCB0aGUgaW1wYWN0IG9mIG91ciByZW5lZ290aWF0aW9uIGF0dGFjayBpcyBjb21wYXJh YmxlIHRvIHRoZQ0KPjIwMDkgcmVuZWdvdGlhdGlvbiBhdHRhY2tzLg0KPkluIGZhY3QsIHRoZSBz ZXR1cCBvZiBvdXIgYXR0YWNrIGlzIGNsb3NlciB0byBSZXihr3MgdmVyc2lvbiB0aGFuIFJheaGv cw0KPnZlcnNpb246DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9j dXJyZW50L21zZzAzOTI4Lmh0bWwNCj4NCj4NCj4NCj5hcyBmYXIgYXMgSSBjYW4gc2VlIC0gZm9y IHRoZSAzcmQgc3RlcCBvZiB0aGUgYXR0YWNrLCBpdA0KPnNlZW1zIHRoYXQgTSBqdXN0IHBhc3Nl cyBtZXNzYWdlcyBiYWNrd2FyZHMgYW5kIGZvcndhcmRzIGFuZCBlbmRzIHVwIE5PVA0KPmtub3dp bmcgdGhlIGtleXMgc2hhcmVkIGJ5IEMgYW5kIFMuIEFueSBhdXRoZW50aWNhdGlvbiBwcm90b2Nv bCBpcw0KPnZ1bG5lcmFibGUgdG8gYSAibWVzc2FnZSBwYXNzaW5nIiBhdHRhY2sgb2YgdGhpcyB0 eXBlIGluIHdoaWNoIHRoZQ0KPmFkdmVyc2FyeSBzaW1wbHkgYWN0cyBhcyBhIHdpcmUsIGFuZCBp dCdzIG5vdCBjb25zaWRlcmVkIGFuIGF0dGFjayBvbiBzdWNoDQo+cHJvdG9jb2xzLg0KPg0KPg0K Pg0KPg0KPkkgd291bGQgbm90ZSB0aGF0IHRoZSByZW5lZ290aWF0aW9uIGhhbmRzaGFrZSB3ZSBh cmUgc3BlYWtpbmcgYWJvdXQgaXMNCj5ub3QgZXhhY3RseSBhIHN0YW5kYWxvbmUgYXV0aGVudGlj YXRpb24gcHJvdG9jb2wuIEl0IGlzIHRoZSBzZWNvbmQNCj5oYW5kc2hha2Ugb24gYSBjb25uZWN0 aW9uLCB3aXRoIGRpZmZlcmVudCBjbGllbnQgb3Igc2VydmVyIGlkZW50aXR5IHRoYW4NCj50aGUg Zmlyc3QgaGFuZHNoYWtlLiBUaGlzIGxlYXZlcyByb29tIGZvcg0KPiBjb25mdXNpb246IHNob3Vs ZCBhbiBpbXBsZW1lbnRhdGlvbiBhc3NvY2lhdGUgdGhlIGNvbm5lY3Rpb24gdG8gdGhlDQo+Zmly c3Qgc2V0IG9mIHByaW5jaXBhbHMgb3IgdGhlIHNlY29uZD8NCj4NCj4NCj4NCj5JbmRlZWQsIGl0 J3MgY29ycmVjdCB0aGF0IEMgKmlzKiBjb25uZWN0ZWQgdG8gUyBhbmQgUyAqaXMqIGNvbm5lY3Rl ZCB0byBDDQo+YWZ0ZXIgc3RlcCAzISAobm90IGp1c3QgdGhhdCB0aGV5ICJ0aGluayIgdGhleSBh cmUgc28tY29ubmVjdGVkKS4NCj4NCj4NCj4NCj4NCj5LZW5ueSwgeW91IHNlZW0gdG8gc3VnZ2Vz dCB0aGF0IG9ubHkgdGhlIHNlY29uZCBzaG91bGQgYmUgY29uc2lkZXJlZC4NCj5Db21tb24gd2Vi IGJyb3dzZXJzIGFuZCBIVFRQUyBsaWJyYXJpZXMgb25seSBjb25zaWRlciB0aGUgZmlyc3QuIEl0 IGlzDQo+aW50ZXJlc3RpbmcgdG8gdHJ5IGFuZCB1bmRlcnN0YW5kIHdoaWNoIGlzIHRoZSByaWdo dCBhbnN3ZXIgaGVyZS4NCj4NCj4NCj4tS2FydGhpaw0KPg0KPg0KPg0KPg0KPg0KPldoYXQgbWF0 dGVycyBoZXJlIGlzIGhvdyBhIHNlcnZlciBhcHBsaWNhdGlvbiBydW5uaW5nIGF0IFMgaW50ZXJw cmV0cyBkYXRhDQo+dGhhdCBtYXkgaGF2ZSBiZWVuIHNlbnQgdW5kZXIgVExTIHByb3RlY3Rpb24g aW4gdGhlIGZpcnN0IDIgc3RlcHMgaW4gdGhlDQo+YXR0YWNrOiBpdCBtYXkgYXNzdW1lIGl0IGNh bWUgZnJvbSBDIHdoZW4gaW4gZmFjdCBpdCBjYW1lIGZyb20gTS4NCj4NCj5UaGUgbW9yZSBhY2N1 cmF0ZSBkZXNjcmlwdGlvbiBmcm9tIEthcnRoaWsncyB0ZXh0IGlzIHRoaXM6DQo+DQo+U3RlcCAz LiAoUmVuZWdvdGlhdGlvbiBDLU0tUykNCj4NCj4NCj4NCj4uLi4NCj5Cb3RoIGhhbmRzaGFrZXMg Y29tcGxldGUgd2l0aCBuZXcgbXV0dWFsbHktYXV0aGVudGljYXRlZCBzZXNzaW9ucyBhbmQNCj5y ZWNvcmQga2V5cy4NCj5DIG5vdyB0aGlua3MgaXQgaXMgY29ubmVjdGVkIHRvIFMgYW5kIFMgdGhp bmtzIGl0IGlzIGNvbm5lY3RlZCB0byBDLg0KPihNIGRvZXMgbm90IGtub3cgdGhlIG5ldyByZWNv cmQga2V5cyBidXQgaXRzIHByZXZpb3VzIG1lc3NhZ2VzIHRvIFMgb24NCj50aGUgc2FtZSBjb25u ZWN0aW9uDQo+bWF5IGJlIHRyZWF0ZWQgYXMgYXV0aGVudGljYXRlZCBieSBDLikNCj4NCj4NCj4N Cj4NCj5JbmRlZWQsIGl0J3MgY29ycmVjdCB0aGF0IEMgKmlzKiBjb25uZWN0ZWQgdG8gUyBhbmQg UyAqaXMqIGNvbm5lY3RlZCB0byBDDQo+YWZ0ZXIgc3RlcCAzISAobm90IGp1c3QgdGhhdCB0aGV5 ICJ0aGluayIgdGhleSBhcmUgc28tY29ubmVjdGVkKS4NCj4NCj5DaGVlcnMNCj4NCj5LZW5ueQ0K Pg0KPg0KPk9uIDAzLzAzLzIwMTQgMTU6MjAsICJLYXJ0aGlrZXlhbiBCaGFyZ2F2YW4iDQo+PGth cnRoaWtleWFuLmJoYXJnYXZhbkBpbnJpYS5mcj4gd3JvdGU6DQo+DQo+V2UgYXJlIGdvaW5nIHRv IHByZXNlbnQgc29tZSBuZXcgbWFuLWluLXRoZS1taWRkbGUgYXR0YWNrcyBvbiBUTFMNCj5hcHBs aWNhdGlvbnMgaW4gVHVlc2Rhean2cyB3b3JraW5nIGdyb3VwIG1lZXRpbmcuIFRoZXNlIGF0dGFj a3Mgd2VyZQ0KPmZvdW5kIGFzIHBhcnQgb2Ygb3VyIHJlc2VhcmNoIG9uIHRyeWluZyB0byBwcm92 ZSBjcnlwdG9ncmFwaGljDQo+c2VjdXJpdHkgZm9yIGEgVExTIGltcGxlbWVudGF0aW9uIFsxXS4g IFdlIHByZXNlbnRpbmcgc29tZSBvZiB0aGUNCj5tYXRlcmlhbHMgaGVyZSB0byBraWNrLXN0YXJ0 IHNvbWUgZGlzY3Vzc2lvbiBhbmQgZ2V0IGVhcmx5IGNvbW1lbnRzIG9uDQo+b3VyIHByb3Bvc2Vk IGNvdW50ZXJtZWFzdXJlLiBTb21lIHBlb3BsZSBvbiB0aGUgbGlzdCBhbHJlYWR5IGtub3cgb2YN Cj50aGVzZSBhdHRhY2tzIGJ1dCB0aGlzIGlzIHRoZSBmaXJzdCBwdWJsaWMgZGlzY2xvc3VyZS4N Cj4NCj5Nb3JlIGRldGFpbHMgYXJlIGF0IGh0dHBzOi8vc2VjdXJlLXJlc3VtcHRpb24uY29tDQo+ PGh0dHBzOi8vc2VjdXJlLXJlc3VtcHRpb24uY29tLz4gWzJdDQo+DQo+U2NlbmFyaW8NCj49PT09 PT0NCj5Db25zaWRlciBhIGNsaWVudCBDIHRoYXQgbm9ybWFsbHkgYXV0aGVudGljYXRlcyB0byBh IHNlcnZlciBTIHVzaW5nIGENCj5jbGllbnQgY2VydGlmaWNhdGUuICBJZiBDIHVzZXMgdGhlIHNh bWUgY2VydGlmaWNhdGUgdG8gYXV0aGVudGljYXRlIHRvDQo+YSBtYWxpY2lvdXMgc2VydmVyIE0s IHRoZW4gd2Ugc2hvdyB0aGF0IE0gY2FuIHVzZSBDqfZzIGNlcnRpZmljYXRlIHRvDQo+YXV0aGVu dGljYXRlIGl0cyBvd24gY29ubmVjdGlvbiB0byBTLg0KPg0KPlRoZSBhdHRhY2sgcmVsaWVzIG9u IHRoZSBjb21iaW5hdGlvbiBvZiBhbiBpbml0aWFsIFJTQSBvciBESEUNCj5oYW5kc2hha2UsIGZv bGxvd2VkIGJ5IHNlc3Npb24gcmVzdW1wdGlvbiBvbiBhIG5ldyBjb25uZWN0aW9uLA0KPmZvbGxv d2VkIGJ5IGEgY2xpZW50LWF1dGhlbnRpY2F0ZWQgcmVuZWdvdGlhdGlvbi4gRHVyaW5nIHRoZSBm aXJzdCB0d28NCj5oYW5kc2hha2VzLCBDIGhhcyBhIGNvbm5lY3Rpb24gdG8gTSBhbmQgTSBoYXMg YSBjb25uZWN0aW9uIHRvDQo+Uy4gRHVyaW5nIHRoZSB0aGlyZCBoYW5kc2hha2UsIE0gaXMgYWJs ZSB0byBhdXRoZW50aWNhdGUgYXMgQyB0byBTIGFuZA0KPmFzIFMgdG8gQy4NCj4NCj5UaGlzIHNl cnZlci1iYXNlZCBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2sgc2hvdWxkIG5vcm1hbGx5IGhhdmUg YmVlbg0KPnByZXZlbnRlZCBieSB0aGUgUmVuZWdvdGlhdGlvbiBJbmRpY2F0aW9uIChSSSkgZXh0 ZW5zaW9uIFszXSBidXQgYnkNCj5pbmplY3Rpbmcgc2Vzc2lvbiByZXN1bXB0aW9uIGJldHdlZW4g dGhlIHR3byBmdWxsIGhhbmRzaGFrZXMsIHdlIGFyZQ0KPmFibGUgdG8gYnlwYXNzIHRoZSByZW5l Z290aWF0aW9uIGNvdW50ZXJtZWFzdXJlLg0KPg0KPlRyaXBsZSBIYW5kc2hha2UgQXR0YWNrDQo+ PT09PT09PT09PT09PT09PQ0KPkmp9mxsIGJyaWVmbHkgc3VtbWFyaXNlIHRoZSBhdHRhY2sgYmVs b3cgZm9yIGFuIGluaXRpYWwgUlNBIGtleQ0KPmV4Y2hhbmdlLiAgVGhlIHdlYnBhZ2UgWzJdIGhh cyBkaWFncmFtcyB0aGF0IHdpbGwgYmUgZWFzaWVyIHRvIGZvbGxvdywNCj5kZXNjcmliZXMgbW9y ZSBhdHRhY2sgdmFyaWFudHMsIGFuZCBwcm92aWRlcyBzb21lIGRpc2Nsb3N1cmUgc3RhdHVzLg0K Pg0KPlRoZSBhdHRhY2sgcHJvY2VlZHMgaW4gdGhyZWUgc3RlcHM6DQo+DQo+U3RlcCAxLiAoSW5p dGlhbCBIYW5kc2hha2VzIEMtTSwgTS1TKQ0KPi0gQyBjb25uZWN0cyB0byBNIGFuZCBNIGNvbm5l Y3RzIHRvIFMsIGJvdGggaGFuZHNoYWtlcyB1c2UgUlNBLg0KPi0gTSBmb3J3YXJkcyBDqfZzIGFu ZCBTqfZzIGNsaWVudCBoZWxsb3MgdG8gZWFjaCBvdGhlci4NCj4tIE0gcmVjZWl2ZXMgYW4gZW5j cnlwdGVkIFBNUyBmcm9tIEMgYW5kIHJlZW5jcnlwdHMgaXQgdG93YXJkcyBTLg0KPi0gQm90aCBo YW5kc2hha2VzIGNvbXBsZXRlIHdpdGggbmV3IHNlc3Npb25zIGFuZCByZWNvcmQga2V5cy4NCj4g Qm90aCBzZXNzaW9ucyBoYXZlIHRoZSBzYW1lIG1hc3RlciBzZWNyZXQsIHJhbmRvbSBub25jZXMs IGFuZCBzZXNzaW9uIGlkLg0KPiAoTSBrbm93cyB0aGUgbWFzdGVyIHNlY3JldCBhbmQgcmVjb3Jk IGtleXMgc2luY2UgaXQgcGFydGljaXBhdGVkIGluIGJvdGgNCj5oYW5kc2hha2VzKQ0KPg0KPlN0 ZXAgMi4gKFNlc3Npb24gUmVzdW1wdGlvbiBDLU0sIE0tUykNCj4tIEMgcmVzdW1lcyBpdHMgc2Vz c2lvbiB3aXRoIE0gb24gYSBuZXcgY29ubmVjdGlvbi4NCj4tIE0gcmVzdW1lcyBpdHMgc2Vzc2lv biB3aXRoIFMgb24gYSBuZXcgY29ubmVjdGlvbi4NCj4tIE0gZm9yd2FyZHMgYWxsIHRoZSBhYmJy ZXZpYXRlZCBoYW5kc2hha2UgbWVzc2FnZXMgdW5jaGFuZ2VkIGJldHdlZW4gQw0KPmFuZCBTLg0K Pi0gTm90ZSB0aGF0IHRoZSBSSSBleHRlbnNpb25zIG9uIGJvdGggaGFuZHNoYWtlcyBhcmUgZW1w dHksDQo+IHNpbmNlIGl0IGlzIHRoZSBmaXJzdCBoYW5kc2hha2Ugb24gdGhlIGNvbm5lY3Rpb24N Cj4tIEJvdGggaGFuZHNoYWtlcyBjb21wbGV0ZSB3aXRoIG5ldyByZWNvcmQga2V5cyAoYW5kIHJl dXNlIG9sZCBzZXNzaW9ucykNCj4gQm90aCBjb25uZWN0aW9ucyBoYXZlIHRoZSBzYW1lIHJlY29y ZCBrZXlzIGFuZCBoYW5kc2hha2UgbG9ncyAodmVyaWZ5DQo+ZGF0YSkNCj4gKE0gc3RpbGwga25v d3MgdGhlIHJlY29yZCBrZXlzIGFuZCBjYW4gc2VuZCBtZXNzYWdlcyBpbiBlaXRoZXINCj5kaXJl Y3Rpb24uKQ0KPg0KPlN0ZXAgMy4gKFJlbmVnb3RpYXRpb24gQy1NLVMpDQo+LSBTIHJlcXVlc3Rz IE0gZm9yIHJlbmVnb3RpYXRpb24gd2l0aCBjbGllbnQgY2VydGlmaWNhdGUuDQo+IE0gcmVxdWVz dHMgQyBmb3IgcmVuZWdvdGlhdGlvbiB3aXRoIGNsaWVudCBjZXJ0aWZpY2F0ZS4NCj4tIE0gZm9y d2FyZHMgYWxsIHJlbmVnb3RpYXRpb24gbWVzc2FnZXMgdW5jaGFuZ2VkIGJldHdlZW4gQyBhbmQg Uw0KPi0gTm90ZSB0aGF0IHNpbmNlIHRoZSBoYW5kc2hha2UgbG9ncyBpbiB0aGUgcHJlY2VkaW5n IGhhbmRzaGFrZSB3ZXJlIHRoZQ0KPnNhbWUsIA0KPiB0aGUgUkkgZXh0ZW5zaW9ucyBvbiBib3Ro IGhhbmRzaGFrZXMgd2lsbCBiZSB0aGUgc2FtZS4NCj4tIEJvdGggaGFuZHNoYWtlcyBjb21wbGV0 ZSB3aXRoIG5ldyBtdXR1YWxseS1hdXRoZW50aWNhdGVkIHNlc3Npb25zIGFuZA0KPnJlY29yZCBr ZXlzLg0KPiBDIG5vdyB0aGlua3MgaXQgaXMgY29ubmVjdGVkIHRvIFMgYW5kIFMgdGhpbmtzIGl0 IGlzIGNvbm5lY3RlZCB0byBDLg0KPiAoTSBkb2VzIG5vdCBrbm93IHRoZSBuZXcgcmVjb3JkIGtl eXMgYnV0IGl0cyBwcmV2aW91cyBtZXNzYWdlcyB0byBTIG9uDQo+dGhlIHNhbWUgY29ubmVjdGlv bg0KPiBtYXkgYmUgdHJlYXRlZCBhcyBhdXRoZW50aWNhdGVkIGJ5IEMuKQ0KPg0KPkF0IHRoZSBl bmQgb2YgU3RlcCAzLCBTIGhhcyBhbiBpbmNvbWluZyBjb25uZWN0aW9uIG9uIHdoaWNoIGl0DQo+ aW5pdGlhbGx5IHJlY2VpdmVkIGRhdGEgZnJvbSBhbiBhbm9ueW1vdXMgY2xpZW50IChNKSBhbmQg bGF0ZXINCj5yZWNlaXZlZCBkYXRhIGZyb20gYW4gYXV0aGVudGljYXRlZCBjbGllbnQgKEMpLiBU aGlzIGJyZWFrcyB0aGUNCj5pbnRlbmRlZCBndWFyYW50ZWVzIG9mIHRoZSBSSSBleHRlbnNpb24u DQo+DQo+Q291bnRlcm1lYXN1cmVzIA0KPj09PT09PT09PT09DQo+RHVyaW5nIFN0ZXAgMywgQyBo YXMgYSBjb25uZWN0aW9uIG9uIHdoaWNoIGl0IGZpcnN0IHJlY2VpdmVkIE2p9nMNCj5jZXJ0aWZp Y2F0ZSBhbmQgbGF0ZXIgU6n2cyBjZXJ0aWZpY2F0ZS4gSWYgQyByZWZ1c2VzIHRvIGFjY2VwdCB0 aGlzDQo+Y2hhbmdlIG9mIHNlcnZlciBpZGVudGl0eSwgdGhlbiBpdCBjYW4gcHJldmVudCBTdGVw IDMgb2YgdGhlDQo+YXR0YWNrLiBJbmRlZWQsIHdlIHJlY29tbWVuZCBtYWluc3RyZWFtIHdlYiBi cm93c2VycyBhbmQgSFRUUFMNCj5saWJyYXJpZXMgc2hvdWxkIHN5c3RlbWF0aWNhbGx5IGZvcmJp ZCB0aGUgY2hhbmdlIG9mIHNlcnZlciBpZGVudGl0aWVzDQo+ZHVyaW5nIHJlbmVnb3RpYXRpb24u DQo+DQo+SG93ZXZlciwgYWxyZWFkeSBhdCB0aGUgZW5kIG9mIFN0ZXAgMiwgYSBudW1iZXIgb2Yg Y29ubmVjdGlvbiBhbmQNCj5zZXNzaW9uIHBhcmFtZXRlcnMsIHN1Y2ggYXMgdGhlIHRscy11bmlx dWUgY2hhbm5lbCBiaW5kaW5nIGZvciB0aGUgdHdvDQo+Y29ubmVjdGlvbnMgYXJlIHRoZSBzYW1l LiBTbyBhbnkgYXBwbGljYXRpb24tbGV2ZWwgbWVjaGFuaXNtIHRoYXQNCj5yZWxpZXMgb24gdGhl IFRMUyBtYXN0ZXIgc2VjcmV0IFs0XSBvciBjaGFubmVsIGJpbmRpbmdzIFs1XSBvciBleHBvcnRz DQo+VExTIGtleWluZyBtYXRlcmlhbCBbNl0gaXMgdnVsbmVyYWJsZSB0byBhIHNpbWlsYXIgbWFu LWluLXRoZS1taWRkbGUNCj5hdHRhY2suDQo+DQo+V2UgYXJndWUgdGhhdCB0aGUgY29yZSB2dWxu ZXJhYmlsaXR5IGhlcmUgaXMgdGhhdCB0aGUgVExTIG1hc3Rlcg0KPnNlY3JldCBpcyBub3QgYm91 bmQgdG8gZW5vdWdoIGVsZW1lbnRzIG9mIHRoZSBUTFMgc2Vzc2lvbi4gV2UgcHJvcG9zZQ0KPmEg bmV3IFRMUyBleHRlbnNpb24gdGhhdCBiaW5kcyB0aGUgbWFzdGVyIHNlY3JldCB0byB0aGUgaGFz aCBvZiB0aGUNCj5hbGwgcmVsZXZhbnQgaGFuZHNoYWtlIG1lc3NhZ2VzIGluIHRoZSBpbml0aWFs IGhhbmRzaGFrZS4NCj4NCj5UaGUgcHJvcG9zZWQgZHJhZnQgaXMgYXZhaWxhYmxlIGF0Og0KPmh0 dHA6Ly9zZWN1cmUtcmVzdW1wdGlvbi5jb20vZHJhZnQtYmhhcmdhdmFuLXRscy1zZXNzaW9uLWhh c2gtMDAudHh0DQo+DQo+VGhlIGtleSBpZGVhIGlzIHRoYXQgZWFjaCBmdWxsIGhhbmRzaGFrZSBp cyBhc3NvY2lhdGVkIHdpdGggYSBzZXNzaW9uDQo+aGFzaCwgY29tcHV0ZWQgYXMNCj4NCj5zZXNz aW9uX2hhc2ggPSBIYXNoKGhhbmRzaGFrZV9tZXNzYWdlcykNCj4NCj53aGVyZSBoYW5kc2hha2Vf bWVzc2FnZXMgY29uc2lzdCBvZiBhbGwgbWVzc2FnZXMgdXAgdG8gYW5kIGluY2x1ZGluZw0KPnRo ZSBDbGllbnRLZXlFeGNoYW5nZS4gIFRoZSBleHRlbmRlZCBtYXN0ZXIgc2VjcmV0IGNvbXB1dGF0 aW9uIGVuYWJsZWQNCj5ieSB0aGUgZXh0ZW5zaW9uIGlzIHRoZW4gY29tcHV0ZWQgYXMNCj4NCj5t YXN0ZXJfc2VjcmV0ID0gUFJGKHByZV9tYXN0ZXJfc2VjcmV0LA0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICJleHRlbmRlZCBtYXN0ZXIgc2VjcmV0IiwNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2Vzc2lvbl9oYXNoKSBbMC4uNDddOw0K Pg0KPldlqfZ2ZSBpbXBsZW1lbnRlZCB0aGlzIGV4dGVuc2lvbiBpbiBPcGVuU1NMIHdpdGhvdXQg bXVjaCBkaWZmaWN1bHR5Lg0KPkNoYW5naW5nIHRoZSBtYXN0ZXIgc2VjcmV0IGRlcml2YXRpb24g bWF5IHNlZW0gcmFkaWNhbCwgYnV0IHdlIGJlbGlldmUNCj5pdCBpcyB0aGUgbWFpbiB3YXkgdG8g Y291bnRlciBmdXR1cmUgYXR0YWNrcyB0aGF0IG1heSByZWx5IG9uIHRoZQ0KPnNlc3Npb24gc3lu Y2hyb25pemF0aW9uIChzdGVwIDEpIHRoYXQgd2UgZXhwbG9pdCBoZXJlLg0KPg0KPkFuIGFsdGVy bmF0aXZlIGNvdW50ZXJtZWFzdXJlIHdvdWxkIGJlIGFuIGV4dGVuc2lvbiAoYWxvbmcgdGhlIGxp bmVzDQo+b2YgWzNdKSB0aGF0IGluY2x1ZGVzIHRoZSBzZXNzaW9uIGhhc2ggYXMgZGVmaW5lZCBh Ym92ZSBpbiB0aGUNCj5DbGllbnRIZWxsbyBhbmQgU2VydmVySGVsbG8gbWVzc2FnZXMgb2YgdGhl IGFiYnJldmlhdGVkDQo+aGFuZHNoYWtlLiBUaGlzIHdvdWxkIHByb3ZpZGUgYW4gZXhwbGljaXQg bGluayBiZXR3ZWVuIHRoZSByZXN1bXB0aW9uDQo+aGFuZHNoYWtlIGFuZCBpdHMgb3JpZ2luYWwg ZnVsbCBoYW5kc2hha2UsIGFuZCBoZW5jZSBwcmV2ZW50IHRoZQ0KPnJlbmVnb3RpYXRpb24gYXR0 YWNrIGRlc2NyaWJlZCBhYm92ZS4NCj4NCj5XZSB3ZWxjb21lIGNvbW1lbnRzIGFuZCBzdWdnZXN0 aW9ucy4NCj4tS2FydGhpayBCaGFyZ2F2YW4sIEFudG9pbmUgRGVsaWduYXQtTGF2YXVkLCBhbmQg QWxmcmVkbyBQaXJvbnRpDQo+DQo+WzFdIGh0dHA6Ly9taXRscy5vcmcgPGh0dHA6Ly9taXRscy5v cmcvPg0KPlsyXSBodHRwczovL3NlY3VyZS1yZXN1bXB0aW9uLmNvbSA8aHR0cHM6Ly9zZWN1cmUt cmVzdW1wdGlvbi5jb20vPg0KPlszXSBSRkM1NzQ2OiBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkg UmVuZWdvdGlhdGlvbiBJbmRpY2F0aW9uIEV4dGVuc2lvbg0KPls0XSBUaGUgQ29tcG91bmQgQXV0 aGVudGljYXRpb24gQmluZGluZyBQcm9ibGVtDQo+KGRyYWZ0LXB1dGhlbmt1bGFtLWVhcC1iaW5k aW5nLTA0KQ0KPls1XSBSRkM1OTI5OiBDaGFubmVsIEJpbmRpbmdzIGZvciBUTFMNCj5bNl0gUkZD NTcwNTogS2V5aW5nIE1hdGVyaWFsIEV4cG9ydGVycyBmb3IgVHJhbnNwb3J0IExheWVyIFNlY3Vy aXR5DQo+DQo+DQo+DQo+DQo+DQoNCg== From nobody Mon Mar 3 09:07:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0141A0258 for ; Mon, 3 Mar 2014 09:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 wsQ8NDhWdBKX for ; Mon, 3 Mar 2014 09:07:08 -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 347341A0256 for ; Mon, 3 Mar 2014 09:07:08 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id id10so3912488vcb.27 for ; Mon, 03 Mar 2014 09:07:05 -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=/fxVLpg12Uwke1xSEbccD0FkeKFVgjoGJJmoE8ZxUVs=; b=FYaIAJDN0gN7oWfTlLtm44yzo/gIXhx3pjSXGHgRGVJVMAEp7f0o0vHBELr/JOM514 5QQFTeapQVK+2G2RFCSncX51pw71g7nWony179ZAKfQhGNzidQXJQEsBTQEgOkZqe7Mw 9G9K+J7xbN2UEQD23n7Nc2SnOa3K0XhA754HZsmUB7h+ovrXElorZbfE+Iy4EaTrVpLw tG2CD9NmWzc+cc1Y7iYi731Ud+BOIqGnPx/f1TccG9GWDFfGFdurKielfnVAUiGeUptz 3T2X63qaWeS5sX8YXdo/JCNhdj5fYic8N1gJ0qauyh79/KLpHrx42Br6dtc5qOSo+Fsx 6dEQ== 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=/fxVLpg12Uwke1xSEbccD0FkeKFVgjoGJJmoE8ZxUVs=; b=LZYyWBEC1ZhBLUzicMNDZ008u+lIP07Z6nBGhN8VEnMv0zhTcdxaQ7+hdSFYgroFYi cotu/I28x7LYUCJhSY5WbSDlTVkNQc9KGj32MoEZtFfwwpzKUpw/QqiCmWjR84eoD+Ya U2RPk+F0zKnLVPFswoa2SU3W0jtvBf1sAPeNJybJtZnMNfWD937T0BMWVJCIM1LTlErz 1abV66OCd/OD7dnx8IOZ20rMh/TIsXVlK1TTw4nQUqMsEGRle3wp7g1fqgn4dbHjC160 QSLA5ay3YtcKd6Xmp0aJPx5GBRVp2/jGp4uMpieTF43dS/xT8Iq6TXTU7pdg2feB9gs1 UqLw== X-Gm-Message-State: ALoCoQmUpatXxedING3Mjz1eGbHUntI9ylsepvSk1+HYTBS/MT4JpBmM9XuqZEF4Kr2wlz6fBYMVqbxl1oaeVBSG7RBl3PqXPYVqc1dOkdqAcpTUVeYOG90z+sdfkf3s52ngi1w0jDqXvCTAHQITGyQixDNm/rvel2JBc6UVgoSXUfTK5njSGA7zWmANrpnEuMQW2kDbA4bG X-Received: by 10.58.133.15 with SMTP id oy15mr17292614veb.19.1393866425151; Mon, 03 Mar 2014 09:07:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Mon, 3 Mar 2014 09:06:45 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Mon, 3 Mar 2014 12:06:45 -0500 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KmLy5jLKqFJUae1xbIC0_Qwjlvk Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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, 03 Mar 2014 17:07:10 -0000 On Mon, Mar 3, 2014 at 11:47 AM, Martin Thomson wrote: > This would prevent the use of false start, would it not? I don't believe so, unless I've missed something. This doesn't delay the master-secret's availability and so I don't see that it would impact False Start. Cheers AGL From nobody Mon Mar 3 11:37:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2621A0351 for ; Mon, 3 Mar 2014 11:37:48 -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 1ig61b_fiVaj for ; Mon, 3 Mar 2014 11:37:44 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 525CA1A0335 for ; Mon, 3 Mar 2014 11:37:44 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s23JbbJF025240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Mar 2014 20:37:37 +0100 (MET) In-Reply-To: <5314AF9B.8000402@drh-consultancy.co.uk> To: Dr Stephen Henson Date: Mon, 3 Mar 2014 20:37:37 +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: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zNtKp3H59Hd7tWRvh399TZK5tbE Cc: tls@ietf.org Subject: Re: [TLS] MITM Attacks on Client Authentication after Resumption 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, 03 Mar 2014 19:37:48 -0000 Dr Stephen Henson wrote: > > If the client checks the hostname against the certificate whenever a > certificate is presented[2] then additionally the attacker needs a certificate > with the same hostname as the attacked server. > > 2. This isn't always the case. Some applications check the hostname only after > the handshake has completed. An application client that is using a TLS library _without_ callbacks, and requests a blocking TLS handshake to be performed, will only get to see the server certificate after the handshake has completed. While the X.509 cert chain validation might be performed in-band by the TLS stack, the rfc2818 Section 3.1 server endpoint identification is left up to the application caller. -Martin From nobody Mon Mar 3 13:07:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD4F1A0091 for ; Mon, 3 Mar 2014 13:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, 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 nXBQYtnaNya2 for ; Mon, 3 Mar 2014 13:07:10 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id A0F1D1A009E for ; Mon, 3 Mar 2014 13:07:10 -0800 (PST) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB594.namprd03.prod.outlook.com (10.255.109.37) with Microsoft SMTP Server (TLS) id 15.0.888.9; Mon, 3 Mar 2014 21:07:05 +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.0888.003; Mon, 3 Mar 2014 21:07:05 +0000 From: Andrei Popov To: Karthikeyan Bhargavan , "Paterson, Kenny" Thread-Topic: [TLS] MITM Attacks on Client Authentication after Resumption Thread-Index: AQHPNvQ2kdkEhddKuUKMTp+XAxT5yZrPjb+AgAAEsoCAAEQTEA== Date: Mon, 3 Mar 2014 21:07: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: [109.144.230.166] x-forefront-prvs: 0139052FDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(24454002)(479174003)(377454003)(189002)(199002)(164054003)(93136001)(95666003)(85306002)(87936001)(74706001)(87266001)(56776001)(86612001)(19300405004)(81542001)(46102001)(51856001)(4396001)(93516002)(81686001)(79102001)(77982001)(59766001)(74366001)(76482001)(54316002)(76786001)(74876001)(50986001)(2656002)(74502001)(56816005)(15202345003)(47736001)(47446002)(49866001)(80022001)(15975445006)(95416001)(53806001)(54356001)(74662001)(31966008)(83072002)(66066001)(65816001)(83322001)(86362001)(69226001)(76796001)(90146001)(85852003)(33646001)(47976001)(92566001)(76576001)(16601075003)(80976001)(15395725003)(94946001)(19580395003)(16236675002)(19580405001)(81342001)(63696002)(94316002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB594; H:BL2PR03MB419.namprd03.prod.outlook.com; CLIP:109.144.230.166; FPR:E41CF1F4.A6FA5392.BDF7718B.40299190.20751; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_b38d76f917ce46ca8d673928d35eb76dBL2PR03MB419namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2I3EePF7sY7LZc9zHctHkTkBpN8 Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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, 03 Mar 2014 21:07:18 -0000 --_000_b38d76f917ce46ca8d673928d35eb76dBL2PR03MB419namprd03pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =D8 I would note that the renegotiation handshake we are speaking about is= not exactly a standalone authentication protocol. It is the second handsha= ke on a connection, with different client or server identity than the first= handshake. This leaves room for confusion: should an implementation associ= ate the connection to the first set of principals or the second? When a renegotiation happens, the TLS client must validate the newly negoti= ated parameters, including the server cert, the cipher suites, Finished has= h, etc. A TLS client that neglects to validate the server certificate after= renegotiation simply has a bug. It appears that the attack described is only feasible when two implementati= on defects are present: 1. TLS implementation error in the client (failure to validate the se= rver cert), and 2. A server application that associates data received from an unauthe= nticated client with the data received after enabling TLS client authentica= tion. While we cannot prevent the latter at the TLS protocol layer, I believe fix= ing the bug in the TLS client effectively thwarts this attack. Thanks, Andrei From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Karthikeyan Bhargavan Sent: Monday, March 3, 2014 4:47 PM To: Paterson, Kenny Cc: tls@ietf.org Subject: Re: [TLS] MITM Attacks on Client Authentication after Resumption Rather, an application running at C might end up using TLS-protected data that was supplied by M in step 2 of the attack as if it came from S (or vice-versa). This is a comparable attack to the original renegotiation attack of Ray&Dispensa and Rex. Yes, indeed, the impact of our renegotiation attack is comparable to the 20= 09 renegotiation attacks. In fact, the setup of our attack is closer to Rex's version than Ray's vers= ion: http://www.ietf.org/mail-archive/web/tls/current/msg03928.html as far as I can see - for the 3rd step of the attack, it seems that M just passes messages backwards and forwards and ends up NOT knowing the keys shared by C and S. Any authentication protocol is vulnerable to a "message passing" attack of this type in which the adversary simply acts as a wire, and it's not considered an attack on such protocols. I would note that the renegotiation handshake we are speaking about is not = exactly a standalone authentication protocol. It is the second handshake on= a connection, with different client or server identity than the first hand= shake. This leaves room for confusion: should an implementation associate t= he connection to the first set of principals or the second? Indeed, it's correct that C *is* connected to S and S *is* connected to C after step 3! (not just that they "think" they are so-connected). Kenny, you seem to suggest that only the second should be considered. Commo= n web browsers and HTTPS libraries only consider the first. It is interesti= ng to try and understand which is the right answer here. -Karthik What matters here is how a server application running at S interprets data that may have been sent under TLS protection in the first 2 steps in the attack: it may assume it came from C when in fact it came from M. The more accurate description from Karthik's text is this: Step 3. (Renegotiation C-M-S) ... Both handshakes complete with new mutually-authenticated sessions and record keys. C now thinks it is connected to S and S thinks it is connected to C. (M does not know the new record keys but its previous messages to S on the same connection may be treated as authenticated by C.) Indeed, it's correct that C *is* connected to S and S *is* connected to C after step 3! (not just that they "think" they are so-connected). Cheers Kenny On 03/03/2014 15:20, "Karthikeyan Bhargavan" > wro= te: We are going to present some new man-in-the-middle attacks on TLS applications in Tuesday=B9s working group meeting. These attacks were found as part of our research on trying to prove cryptographic security for a TLS implementation [1]. We presenting some of the materials here to kick-start some discussion and get early comments on our proposed countermeasure. Some people on the list already know of these attacks but this is the first public disclosure. More details are at https://secure-resumption.com [2] Scenario =3D=3D=3D=3D=3D=3D Consider a client C that normally authenticates to a server S using a client certificate. If C uses the same certificate to authenticate to a malicious server M, then we show that M can use C=B9s certificate to authenticate its own connection to S. The attack relies on the combination of an initial RSA or DHE handshake, followed by session resumption on a new connection, followed by a client-authenticated renegotiation. During the first two handshakes, C has a connection to M and M has a connection to S. During the third handshake, M is able to authenticate as C to S and as S to C. This server-based man-in-the-middle attack should normally have been prevented by the Renegotiation Indication (RI) extension [3] but by injecting session resumption between the two full handshakes, we are able to bypass the renegotiation countermeasure. Triple Handshake Attack =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I=B9ll briefly summarise the attack below for an initial RSA key exchange. The webpage [2] has diagrams that will be easier to follow, describes more attack variants, and provides some disclosure status. The attack proceeds in three steps: Step 1. (Initial Handshakes C-M, M-S) - C connects to M and M connects to S, both handshakes use RSA. - M forwards C=B9s and S=B9s client hellos to each other. - M receives an encrypted PMS from C and reencrypts it towards S. - Both handshakes complete with new sessions and record keys. Both sessions have the same master secret, random nonces, and session id. (M knows the master secret and record keys since it participated in both handshakes) Step 2. (Session Resumption C-M, M-S) - C resumes its session with M on a new connection. - M resumes its session with S on a new connection. - M forwards all the abbreviated handshake messages unchanged between C and S. - Note that the RI extensions on both handshakes are empty, since it is the first handshake on the connection - Both handshakes complete with new record keys (and reuse old sessions) Both connections have the same record keys and handshake logs (verify data) (M still knows the record keys and can send messages in either direction.) Step 3. (Renegotiation C-M-S) - S requests M for renegotiation with client certificate. M requests C for renegotiation with client certificate. - M forwards all renegotiation messages unchanged between C and S - Note that since the handshake logs in the preceding handshake were the same, the RI extensions on both handshakes will be the same. - Both handshakes complete with new mutually-authenticated sessions and record keys. C now thinks it is connected to S and S thinks it is connected to C. (M does not know the new record keys but its previous messages to S on the same connection may be treated as authenticated by C.) At the end of Step 3, S has an incoming connection on which it initially received data from an anonymous client (M) and later received data from an authenticated client (C). This breaks the intended guarantees of the RI extension. Countermeasures =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D During Step 3, C has a connection on which it first received M=B9s certificate and later S=B9s certificate. If C refuses to accept this change of server identity, then it can prevent Step 3 of the attack. Indeed, we recommend mainstream web browsers and HTTPS libraries should systematically forbid the change of server identities during renegotiation. However, already at the end of Step 2, a number of connection and session parameters, such as the tls-unique channel binding for the two connections are the same. So any application-level mechanism that relies on the TLS master secret [4] or channel bindings [5] or exports TLS keying material [6] is vulnerable to a similar man-in-the-middle attack. We argue that the core vulnerability here is that the TLS master secret is not bound to enough elements of the TLS session. We propose a new TLS extension that binds the master secret to the hash of the all relevant handshake messages in the initial handshake. The proposed draft is available at: http://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt The key idea is that each full handshake is associated with a session hash, computed as session_hash =3D Hash(handshake_messages) where handshake_messages consist of all messages up to and including the ClientKeyExchange. The extended master secret computation enabled by the extension is then computed as master_secret =3D PRF(pre_master_secret, "extended master secret", session_hash) [0..47]; We=B9ve implemented this extension in OpenSSL without much difficulty. Changing the master secret derivation may seem radical, but we believe it is the main way to counter future attacks that may rely on the session synchronization (step 1) that we exploit here. An alternative countermeasure would be an extension (along the lines of [3]) that includes the session hash as defined above in the ClientHello and ServerHello messages of the abbreviated handshake. This would provide an explicit link between the resumption handshake and its original full handshake, and hence prevent the renegotiation attack described above. We welcome comments and suggestions. -Karthik Bhargavan, Antoine Delignat-Lavaud, and Alfredo Pironti [1] http://mitls.org [2] https://secure-resumption.com [3] RFC5746: Transport Layer Security Renegotiation Indication Extension [4] The Compound Authentication Binding Problem (draft-puthenkulam-eap-binding-04) [5] RFC5929: Channel Bindings for TLS [6] RFC5705: Keying Material Exporters for Transport Layer Security --_000_b38d76f917ce46ca8d673928d35eb76dBL2PR03MB419namprd03pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=D8  I would note that= the renegotiation handshake we are speaking about is not exactly a standal= one authentication protocol. It is the second handshake on a connection, with different client or server identity than the first h= andshake. This leaves room for confusion: should an implementation associat= e the connection to the first set of principals or the second?

 <= /p>

When a renegotiation happ= ens, the TLS client must validate the newly negotiated parameters, includin= g the server cert, the cipher suites, Finished hash, etc. A TLS client that neglects to validate the server certificate after renego= tiation simply has a bug.

 <= /p>

It appears that the attac= k described is only feasible when two implementation defects are present:

1. = ;      TLS implementatio= n error in the client (failure to validate the server cert),  and

2. = ;      A server applicat= ion that associates data received from an unauthenticated client with the d= ata received after enabling TLS client authentication.

 <= /p>

While we cannot prevent t= he latter at the TLS protocol layer, I believe fixing the bug in the TLS cl= ient effectively thwarts this attack.

 <= /p>

Thanks,=

 <= /p>

Andrei<= /p>

 

From: TLS [m= ailto:tls-bounces@ietf.org] On Behalf Of Karthikeyan Bhargavan
Sent: Monday, March 3, 2014 4:47 PM
To: Paterson, Kenny
Cc: tls@ietf.org
Subject: Re: [TLS] MITM Attacks on Client Authentication after Resum= ption

 

 

Rather, an application running at C might end up usi= ng TLS-protected data
that was supplied by M in step 2 of the attack as if it came from S (or
vice-versa). This is a comparable attack to the original renegotiation
attack of Ray&Dispensa and Rex.

 

Yes, indeed, the impact of our renegotiation attack = is comparable to the 2009 renegotiation attacks.

In fact, the setup of our attack is closer to Rex= 217;s version than Ray’s version:

 

as far as I can see - for the 3rd step of the attack= , it
seems that M just passes messages backwards and forwards and ends up NOT knowing the keys shared by C and S. Any authentication protocol is
vulnerable to a "message passing" attack of this type in which th= e
adversary simply acts as a wire, and it's not considered an attack on such<= br> protocols.

 

I would note that the renegotiation handshake we are= speaking about is not exactly a standalone authentication protocol. It is = the second handshake on a connection, with different client or server ident= ity than the first handshake. This leaves room for confusion: should an implementation associate the connecti= on to the first set of principals or the second? 

 

Indeed, it's correct that C *is* connected to S and = S *is* connected to C
after step 3! (not just that they "think" they are so-connected).=

 

Kenny, you seem to suggest that only the second shou= ld be considered. Common web browsers and HTTPS libraries only consider the= first. It is interesting to try and understand which is the right answer h= ere.

 

-Karthik

 




What matters here is how a server application running at S interprets data<= br> that may have been sent under TLS protection in the first 2 steps in the attack: it may assume it came from C when in fact it came from M.

The more accurate description from Karthik's text is this:


Step 3. (Renegotiation C-M-S)



...
Both handshakes complete with new mutually-authenticated sessions and
record keys.
C now thinks it is connected to S and S thinks it is connected to C.
(M does not know the new record keys but its previous messages to S on
the same connection
may be treated as authenticated by C.)



Indeed, it's correct that C *is* connected to S and S *is* connected to C after step 3! (not just that they "think" they are so-connected).=

Cheers

Kenny


On 03/03/2014 15:20, "Karthikeyan Bhargavan"
<karthikeyan.bhargavan= @inria.fr> wrote:

We are going to present some new man-in-the-middle attacks on TLS
applications in Tuesday=B9s working group meeting. These attacks were
found as part of our research on trying to prove cryptographic
security for a TLS implementation [1].  We presenting some of the
materials here to kick-start some discussion and get early comments on
our proposed countermeasure. Some people on the list already know of
these attacks but this is the first public disclosure.

More details are at https://secur= e-resumption.com
<https://secure-resumption.co= m/> [2]

Scenario
=3D=3D=3D=3D=3D=3D
Consider a client C that normally authenticates to a server S using a
client certificate.  If C uses the same certificate to authenticate to=
a malicious server M, then we show that M can use C=B9s certificate to
authenticate its own connection to S.

The attack relies on the combination of an initial RSA or DHE
handshake, followed by session resumption on a new connection,
followed by a client-authenticated renegotiation. During the first two
handshakes, C has a connection to M and M has a connection to
S. During the third handshake, M is able to authenticate as C to S and
as S to C.

This server-based man-in-the-middle attack should normally have been
prevented by the Renegotiation Indication (RI) extension [3] but by
injecting session resumption between the two full handshakes, we are
able to bypass the renegotiation countermeasure.

Triple Handshake Attack
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I=B9ll briefly summarise the attack below for an initial RSA key
exchange.  The webpage [2] has diagrams that will be easier to follow,=
describes more attack variants, and provides some disclosure status.

The attack proceeds in three steps:

Step 1. (Initial Handshakes C-M, M-S)
- C connects to M and M connects to S, both handshakes use RSA.
- M forwards C=B9s and S=B9s client hellos to each other.
- M receives an encrypted PMS from C and reencrypts it towards S.
- Both handshakes complete with new sessions and record keys.
 Both sessions have the same master secret, random nonces, and session= id.
 (M knows the master secret and record keys since it participated in b= oth
handshakes)

Step 2. (Session Resumption C-M, M-S)
- C resumes its session with M on a new connection.
- M resumes its session with S on a new connection.
- M forwards all the abbreviated handshake messages unchanged between C
and S.
- Note that the RI extensions on both handshakes are empty,
 since it is the first handshake on the connection
- Both handshakes complete with new record keys (and reuse old sessions)  Both connections have the same record keys and handshake logs (verify=
data)
 (M still knows the record keys and can send messages in either
direction.)

Step 3. (Renegotiation C-M-S)
- S requests M for renegotiation with client certificate.
 M requests C for renegotiation with client certificate.
- M forwards all renegotiation messages unchanged between C and S
- Note that since the handshake logs in the preceding handshake were the same,
 the RI extensions on both handshakes will be the same.
- Both handshakes complete with new mutually-authenticated sessions and
record keys.
 C now thinks it is connected to S and S thinks it is connected to C.<= br>  (M does not know the new record keys but its previous messages to S o= n
the same connection
 may be treated as authenticated by C.)

At the end of Step 3, S has an incoming connection on which it
initially received data from an anonymous client (M) and later
received data from an authenticated client (C). This breaks the
intended guarantees of the RI extension.

Countermeasures
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
During Step 3, C has a connection on which it first received M=B9s
certificate and later S=B9s certificate. If C refuses to accept this
change of server identity, then it can prevent Step 3 of the
attack. Indeed, we recommend mainstream web browsers and HTTPS
libraries should systematically forbid the change of server identities
during renegotiation.

However, already at the end of Step 2, a number of connection and
session parameters, such as the tls-unique channel binding for the two
connections are the same. So any application-level mechanism that
relies on the TLS master secret [4] or channel bindings [5] or exports
TLS keying material [6] is vulnerable to a similar man-in-the-middle
attack.

We argue that the core vulnerability here is that the TLS master
secret is not bound to enough elements of the TLS session. We propose
a new TLS extension that binds the master secret to the hash of the
all relevant handshake messages in the initial handshake.

The proposed draft is available at:
http://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt<= /a>

The key idea is that each full handshake is associated with a session
hash, computed as

session_hash =3D Hash(handshake_messages)

where handshake_messages consist of all messages up to and including
the ClientKeyExchange.  The extended master secret computation enabled=
by the extension is then computed as

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

We=B9ve implemented this extension in OpenSSL without much difficulty.
Changing the master secret derivation may seem radical, but we believe
it is the main way to counter future attacks that may rely on the
session synchronization (step 1) that we exploit here.

An alternative countermeasure would be an extension (along the lines
of [3]) that includes the session hash as defined above in the
ClientHello and ServerHello messages of the abbreviated
handshake. This would provide an explicit link between the resumption
handshake and its original full handshake, and hence prevent the
renegotiation attack described above.

We welcome comments and suggestions.
-Karthik Bhargavan, Antoine Delignat-Lavaud, and Alfredo Pironti

[1] http://mitls.org <http://mitls.org/>
[2] https://secure-resumption.com= <https://secure-resumpti= on.com/>
[3] RFC5746: Transport Layer Security Renegotiation Indication Extension [4] The Compound Authentication Binding Problem
(draft-puthenkulam-eap-binding-04)
[5] RFC5929: Channel Bindings for TLS
[6] RFC5705: Keying Material Exporters for Transport Layer Security

 

--_000_b38d76f917ce46ca8d673928d35eb76dBL2PR03MB419namprd03pro_-- From nobody Mon Mar 3 13:55:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BAC1A0176 for ; Mon, 3 Mar 2014 13:55:37 -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 oiUJMAOQW0NU for ; Mon, 3 Mar 2014 13:55:35 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id AD75D1A00D3 for ; Mon, 3 Mar 2014 13:55:35 -0800 (PST) Received: by mail-yk0-f176.google.com with SMTP id 19so12095364ykq.7 for ; Mon, 03 Mar 2014 13:55: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=nuL/RzZV57MHi1sQ/fuODll17oe2NaSNZSswZfndPsA=; b=GV13yulgcmQdmD+ty0oOO/QpI4ay3vp8rtfgRtIVUJITikGfeoH8q3oymIfMjekI6t zN1q12uhxgyEaTz0qxYP1gWKo+Eoha5e7jqqbsnUWIPybsHWrrUowrkYpguE25RVwjGS A2q+maW+xmn9OZaTyXSWhUW8+zUxsXRA9RpZ3rNBv8qtFDjgSHY6BD2gh3uBKN/yQCJi XwP/EBsxBlEdeBeCuvtGQoay2EESRqrl9EFor1Gna/2ijgunDfI/WNvJIa51Xw5/v0G7 J2NvvhECazSZa10CcC4Lpgi1jztaNcKAfeXOH1OwKVvRgfQLRV+WGUjfMFi8deIWtYi8 zq0g== MIME-Version: 1.0 X-Received: by 10.236.142.198 with SMTP id i46mr9923333yhj.66.1393883732541; Mon, 03 Mar 2014 13:55:32 -0800 (PST) Received: by 10.170.92.85 with HTTP; Mon, 3 Mar 2014 13:55:32 -0800 (PST) Received: by 10.170.92.85 with HTTP; Mon, 3 Mar 2014 13:55:32 -0800 (PST) In-Reply-To: <5314AF9B.8000402@drh-consultancy.co.uk> References: <5314AF9B.8000402@drh-consultancy.co.uk> Date: Mon, 3 Mar 2014 13:55:32 -0800 Message-ID: From: Watson Ladd To: Dr Stephen Henson Content-Type: multipart/alternative; boundary=20cf306849edbc884e04f3bad838 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mjY7sIgMZthXWXPd10u-y_a-X24 Cc: tls@ietf.org Subject: Re: [TLS] MITM Attacks on Client Authentication after 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, 03 Mar 2014 21:55:37 -0000 --20cf306849edbc884e04f3bad838 Content-Type: text/plain; charset=UTF-8 Dear all, This is the third time we've had a bug in the protocol in an area that was supposedly fixed. In this case it's the interaction between two different flows breaking a tacit assumption in the state machine, and the complex semantics of session renegotiation, both of which were previously noticed in 2009 with the Rex/Ray attack. There are two ways to make apparently secure systems: make the system so simple it can't have flaws, and make it so complicated we can't find the flaws. Luckily the authors are completing a verification which should hopefully ensure that there aren't any more flaws. Unluckily we have decided to make TLS 1.3. Will TLS 1.3 actually make a protocol so simple that it has no flaws? Or will it continue to be filled with surprises? Furthermore, I would like to ask the chairs what they plan to do about the clear issues in the process that this has exposed, and why users should continue to trust TLS with confidential information. Username password and cookies continue to be widely used in part because client authentication in TLS has not had a good run. We need a new mechanism for client authentication. Sincerely, Watson Ladd --20cf306849edbc884e04f3bad838 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear all,
This is the third time we've had a bug in the protocol in an area that = was supposedly fixed. In this case it's the interaction between two dif= ferent flows breaking a tacit assumption in the state machine, and the comp= lex semantics of session renegotiation, both of which were previously notic= ed in 2009 with the Rex/Ray attack.

There are two ways to make apparently secure systems: make t= he system so simple it can't have flaws, and make it so complicated we = can't find the flaws. Luckily the authors are completing a verification= which should hopefully ensure that there aren't any more flaws. Unluck= ily we have decided to make TLS 1.3. Will TLS 1.3 actually make a protocol = so simple that it has no flaws? Or will it continue to be filled with surpr= ises?

Furthermore,=C2=A0 I would like to ask the chairs what they = plan to do about the clear issues in the process that this has exposed, and= why users should continue to trust TLS with confidential information.

Username password and cookies continue to be widely used in = part because client authentication in TLS has not had a good run. We need a= new mechanism for client authentication.

Sincerely,
Watson Ladd

--20cf306849edbc884e04f3bad838-- From nobody Mon Mar 3 14:07:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60E51A0148 for ; Mon, 3 Mar 2014 14:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 aleCWYM1npOJ for ; Mon, 3 Mar 2014 14:07:30 -0800 (PST) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 620C31A0136 for ; Mon, 3 Mar 2014 14:07:30 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id sa20so4271813veb.36 for ; Mon, 03 Mar 2014 14:07:27 -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=Wcd2U05+p0nq5KRhUsgFyNeTTnxIsGuitobltWjdzzk=; b=hxsoWH1GGIMHNUFC7mNx82enjdFtsunBTpse3dCJX2lJK0cAPHMD4qzhz5eNQ/0I8H i2vrpa6rSuPXfUiDOVLAkumkyNT7vRASk1RNFgNs3B6LqobBqkyKSp7wpZ2VqhHCoWtn nIQ+BsROS3ojby0p9w4/MbG4IU1RIkjMPQgAPdYjTS/OipOTxLuzBcjvWJVGLtttqfCA zmR6YSxbZRcw/0OmrhaL2z2zNMFKGOFbb/O8+2Hgfa4/MWmiMIpjEhj/UB87osBJyS7z esesank7qc4bjfNeW42xZdd0OVXy1voT6EnpNgkJm7xV52ebQlOwKoVXOvJWCC9qb5SA 2nZA== 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=Wcd2U05+p0nq5KRhUsgFyNeTTnxIsGuitobltWjdzzk=; b=BohgjmY1fkvIwlf557cbujxiqjV0zgY9UQdCJrnPHkAiCDG6e7pxQJxsCu+iz04c5V +5yi24+mGHLsIu+ZALSIqBvD1tG6tjaQOF4OT9KBX/RosSPm4rD6UpLlyqwvq4NV20Ci eY677VF/MJIkXdAxqE23J9EAqXkN10KFd9QzABDOwkCXW6o0LH+OkSgmTBue5bcOtYq5 4T0JuBT2zk5OzugoHwZ0r2zqIxLpNH+bRhUgGEnXJjTTSZYIlycXFxI5pwV1aKSIXdgO JeeW25aUe4wToKB4X7/1DsAtt+Bvajb2tAkWsJwTKo9zTDwp7HHdlUMCEO/l67/oqqQG s+Iw== X-Gm-Message-State: ALoCoQkhzKU+Gz2J3y1E7THkzvcJNYwNyfYuzb6ZDXxBzj73dTj4dnJ3ux/MN2ScMUqwbfftgLtxA+eXKCHfn+PsPahQQVOKR4FN3pBQ6VDRU9/9PdxjEUvqm3P0SapMXjRqL90tVUMJV6Q5iizandlRuY5pJN47OVl8Qcl7AsxmYd3DpQ8mTD0EswypX5N0+LaBj0kxrcWN X-Received: by 10.52.30.230 with SMTP id v6mr1179134vdh.6.1393884446997; Mon, 03 Mar 2014 14:07:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Mon, 3 Mar 2014 14:07:05 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Mon, 3 Mar 2014 17:07:05 -0500 Message-ID: To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mC-_VFLOqFuNKw3q18b4lUD4QTk Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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, 03 Mar 2014 22:07:33 -0000 On Mon, Mar 3, 2014 at 4:07 PM, Andrei Popov wrote: > It appears that the attack described is only feasible when two > implementation defects are present: That's not an unreasonable characterisation of the renegotiation-based attacks, but the problem with tls-unique is more fundamental. Cheers AGL From nobody Mon Mar 3 15:13:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC9C1A024B for ; Mon, 3 Mar 2014 15:13:24 -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 3ruA8XZHHY_k for ; Mon, 3 Mar 2014 15:13:21 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C94891A0249 for ; Mon, 3 Mar 2014 15:13:20 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s23NDGpm004613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Mar 2014 00:13:16 +0100 (MET) In-Reply-To: To: Andrei Popov Date: Tue, 4 Mar 2014 00:13:15 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20140303231316.03E2E1AC37@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/meDw26qN0Vi1YEI-OUBhhbjFTqE Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after Resumption 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, 03 Mar 2014 23:13:24 -0000 Andrei Popov wrote: > > =D8 I would note that the renegotiation handshake we are speaking about > is not exactly a standalone authentication protocol. But we know since at least late 2009 that TLS server that use/allow delayed authentication through renegotiation abuse the rengotiation handshake in EXACTLY such a fashion, they have been turning the mere technical successful completion of a TLS renegotiation handshake into an OTP scheme that authorizes a previously received, unauthenticated request. =20 As I wrote in my 2009 posting about the problem: The victim [] TLS server has no means to detect that it has been attacked. Whether the TLS client cares about receiving a different TLS server cert in the renegotiation handshake and what it will do about it -- if anything, depends entirely on the application of the TLS client. At the TLS level, everything looks just fine. I'm not sure that all clients will repeat the server authentication. They can be expected to verify the server certificate before sending off their request. Depending on the API architecture, they may not always realize or care that a renegotiation was performed while they were sitting on SSL_read() waiting for the server reply. And even if they decide to perform an additional server endpoint identification, they might be doing it after the renegotiate handshake has been successfully completed -- a point where the victim [] TLS server has started performing the action requested in the anonymous request from the MITM. Because of the nature of this problem, that the server reinterprets a technically successful renegotiation handshake into an OTP authentication scheme to authenticate a previously received, unrelated and unauthenticated request, the following guidance was added to rfc5746: http://tools.ietf.org/html/rfc5746#section-5 While this extension mitigates the man-in-the-middle attack described in the overview, it does not resolve all possible problems an application may face if it is unaware of renegotiation. For example, during renegotiation, either the client or the server can present a different certificate than was used earlier. This may come as a surprise to application developers (who might have expected, for example, that a "getPeerCertificates()" API call returns the same value if called twice), and might be handled in an insecure way. TLS implementations SHOULD provide a mechanism to disable and enable renegotiation. TLS implementers are encouraged to clearly document how renegotiation interacts with the APIs offered to applications (for example, which API calls might return different values on different calls, or which callbacks might get called multiple times). To make life simpler for applications that use renegotiation but do not expect the certificate to change once it has been authenticated, TLS implementations may also wish to offer the applications the option to abort the renegotiation if the peer tries to authenticate with a different certificate and/or different server name (in the server_name extension) than was used earlier. TLS implementations may alternatively offer the option to disable renegotiation once the client certificate has been authenticated.=20 > > It is the second handshake on a connection, with different client or > server identity than the first handshake. This leaves room for confusion: > should an implementation associate the connection to the first set > of principals or the second? The guidance from rfc5746 should be clear. The server which is doing delayed authentication through renegotiation is still comitting the sin here. Currently, it dumps the problem and its mitigation for this risky server-side behaviour entirely on the client. >=20 > When a renegotiation happens, the TLS client must validate the newly > negotiated parameters, including the server cert, the cipher suites, > Finished hash, etc. A TLS client that neglects to validate the server > certificate after renegotiation simply has a bug. The problem can easily be an "added value" provided transparently by the underlying TLS client implementation, and the application client may not be aware that it has to cover the ass of the server, who is abusing the renegotiatiation handshake for delayed authentication. >=20 > It appears that the attack described is only feasible when two > implementation defects are present: >=20 > 1. TLS implementation error in the client (failure to validate > the server cert), and After rfc5746 this would be a defect of an rfc5746-enhanced TLS client to "transparently" replace the server cert after the first handshake completed without being explicitly authorized by the application caller to do so. >=20 > 2. A server application that associates data received from an > unauthenticated client with the data received after enabling > TLS client authentication. Requesting TLS clients through renegotiation rather than upfront seems to be pretty common (it even seems to be the default in IIS 7.x), and some browser even have small difficulties being asked for a certificate upfront (such as Safari). >=20 > While we cannot prevent the latter at the TLS protocol layer, > I believe fixing the bug in the TLS client effectively thwarts this attac= k. The original renegotiation problem and the newly describe session resumption problem are very similar: flawed assumptions about a cryptographic binding that doesn't exist. But until you write down the exact properties and think about it, you may not notice the problem. As soon as you write it down, the problem becomes obvious. The abbreviated TLS handshake authenticates only the MasterSecret. But the MasterSecret is derived exclusively from ClientHello.random, ServerHello.random and the keyExchange transform, there is no cryptographic binding to any identities that are authenticated during the TLS handshake. So the fix of the abbreviated TLS handshake needs to account for the (re-)authentication of the identities of the original full handshake, either by modifying the MasterSecret computation or by authenticating the original full handshake during the abbreviated TLS handshake through a TLS extension similar to how the renegotiation_info extension does this in the renegotiation handshake. -Martin From nobody Mon Mar 3 15:32:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223831A00E2 for ; Mon, 3 Mar 2014 15:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmF0esDfyX5s for ; Mon, 3 Mar 2014 15:32:48 -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 A9B3F1A00B6 for ; Mon, 3 Mar 2014 15:32:47 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D32A128578; Mon, 3 Mar 2014 23:32:42 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id BE7D728577; Mon, 3 Mar 2014 23:32:42 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id B686BFE229; Mon, 3 Mar 2014 23:32:42 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.228]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 3 Mar 2014 18:32:42 -0500 From: "Salz, Rich" To: Watson Ladd Date: Mon, 3 Mar 2014 18:32:36 -0500 Thread-Topic: [TLS] MITM Attacks on Client Authentication after Resumption Thread-Index: Ac83K1DgqEl+P4ZCTEq0iA+SB4zYAQADC4Ag Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711EFC3909C@USMBX1.msg.corp.akamai.com> References: <5314AF9B.8000402@drh-consultancy.co.uk> 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_2A0EFB9C05D0164E98F19BB0AF3708C711EFC3909CUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1NYWxuCCYRh3I82_YjG51IXK1rM Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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, 03 Mar 2014 23:32:50 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C711EFC3909CUSMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBib3RoIG9mIHdoaWNoIHdlcmUgcHJldmlvdXNseSBub3RpY2VkIGluIDIwMDkgd2l0aCB0aGUg UmV4L1JheSBhdHRhY2suDQoNCkhtbeKApiAgRm91ci1wbHVzIHllYXJzIGlzIGEgcHJldHR5IGRh cm4gZ29vZCByZWNvcmQsIEnigJlkIHNheS4NCg0KPiB3aHkgdXNlcnMgc2hvdWxkIGNvbnRpbnVl IHRvIHRydXN0IFRMUyB3aXRoIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbi4NCg0KQXQgdGhlIHJp c2sgb2YgYmVpbmcgZmxpcCBvciBzbmFya3ksIGJlY2F1c2UgaXTigJlzIHRoZSBvbmx5IHRoaW5n IHdlIGhhdmUuIFRoZXJlZm9yZSBldmVyeW9uZSB1c2VzIGl0IGFuZCB0aGVyZWZvcmUgdGhlcmUg YXJlIGxvdHMgbW9yZSDigJxpbnRlcmVzdGluZ+KAnSBwbGFjZXMgZm9yIGFuIGFkdmVyc2FyeSB0 byBhdHRhY2suICBBcyB0aGUgb2xkIGpva2UgZ29lcywgSSBkb27igJl0IGhhdmUgdG8gb3V0cnVu IHRoZSBiZWFyLCBJIGp1c3QgaGF2ZSB0byBvdXRydW4geW91Lg0KDQpBdCBvbmUgcG9pbnQsIHRo ZSBtb3N0IGNvbW1vbiB3YXkgYmFua3MgdHJhbnNmZXJyZWQgbW9uZXkgYW1vbmdzdCB0aGVtc2Vs dmVzIHdhcyBQR1Agc2lnbmVkIGRhdGEgb3ZlciBGVFAuIEkgZG9u4oCZdCBrbm93IGlmIGl04oCZ cyBzdGlsbCB0cnVlLiBUaGUgVVMgRmVkZXJhbCBSZXNlcnZlIHJlcXVpcmVzIFRMUyBvdmVyIGRp cmVjdCBsZWFzZWQgbGluZXMgZm9yIGJhbmtzIGRvaW5nIHRyYW5zYWN0aW9ucyBtb3JlIHRoYW4g JDEwTWlsbGlvbi4NCg0KPiBVc2VybmFtZSBwYXNzd29yZCBhbmQgY29va2llcyBjb250aW51ZSB0 byBiZSB3aWRlbHkgdXNlZCBpbiBwYXJ0IGJlY2F1c2UgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlu IFRMUyBoYXMgbm90IGhhZCBhIGdvb2QgcnVuLg0KDQpZb3UgbWVhbiBiZWNhdXNlIGNsaWVudCBj ZXJ0cyBhcmUgbm90IHdpZGVseSBkZXBsb3llZCwgcmlnaHQ/ICBQZXJoYXBzIHNvbWUgbmFtZS9w YmtkZjIgaXMgYmV0dGVyPw0KICAgICAgICAgICAgICAgIC9yJA0KDQotLQ0KUHJpbmNpcGFsIFNl Y3VyaXR5IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5vbG9neQ0KQ2FtYnJpZGdlLCBNQQ0K --_000_2A0EFB9C05D0164E98F19BB0AF3708C711EFC3909CUSMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6MjAxODY0NjExOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczo1OTI4OTg3OTQgMTI3NDYwNzU4NiA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpA bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjQ0Ow0KCW1zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCglj b2xvcjojMUY0OTdEO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxDQoJe21zby1saXN0LWlkOjI2MjU2NzAyMzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTIwMDI0OTEzMjIgLTEzNDg5OTE1NTQgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo0NDsNCgltc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7DQoJY29sb3I6IzFGNDk3RDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2 IGNsYXNzPVdvcmRTZWN0aW9uMT48cD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jmd0Ozwv c3Bhbj4gYm90aCBvZiB3aGljaCB3ZXJlIHByZXZpb3VzbHkgbm90aWNlZCBpbiAyMDA5IHdpdGgg dGhlIFJleC9SYXkgYXR0YWNrLjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5IbW3igKbCoCBGb3VyLXBsdXMg eWVhcnMgaXMgYSBwcmV0dHkgZGFybiBnb29kIHJlY29yZCwgSeKAmWQgc2F5LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jmd0OyA8L3NwYW4+d2h5 IHVzZXJzIHNob3VsZCBjb250aW51ZSB0byB0cnVzdCBUTFMgd2l0aCBjb25maWRlbnRpYWwgaW5m b3JtYXRpb24uPHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkF0IHRoZSByaXNrIG9mIGJlaW5nIGZsaXAgb3Ig c25hcmt5LCBiZWNhdXNlIGl04oCZcyB0aGUgb25seSB0aGluZyB3ZSBoYXZlLiBUaGVyZWZvcmUg ZXZlcnlvbmUgdXNlcyBpdCBhbmQgdGhlcmVmb3JlIHRoZXJlIGFyZSBsb3RzIG1vcmUg4oCcaW50 ZXJlc3RpbmfigJ0gcGxhY2VzIGZvciBhbiBhZHZlcnNhcnkgdG8gYXR0YWNrLsKgIEFzIHRoZSBv bGQgam9rZSBnb2VzLCBJIGRvbuKAmXQgaGF2ZSB0byBvdXRydW4gdGhlIGJlYXIsIEkganVzdCBo YXZlIHRvIG91dHJ1biB5b3UuPG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+QXQgb25lIHBvaW50LCB0aGUgbW9zdCBjb21tb24gd2F5IGJhbmtzIHRyYW5zZmVy cmVkIG1vbmV5IGFtb25nc3QgdGhlbXNlbHZlcyB3YXMgUEdQIHNpZ25lZCBkYXRhIG92ZXIgRlRQ LiBJIGRvbuKAmXQga25vdyBpZiBpdOKAmXMgc3RpbGwgdHJ1ZS4gVGhlIFVTIEZlZGVyYWwgUmVz ZXJ2ZSByZXF1aXJlcyBUTFMgb3ZlciBkaXJlY3QgbGVhc2VkIGxpbmVzIGZvciBiYW5rcyBkb2lu ZyB0cmFuc2FjdGlvbnMgbW9yZSB0aGFuICQxME1pbGxpb24uPG86cD48L286cD48L3NwYW4+PC9w PjxwPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mZ3Q7IDwvc3Bhbj5Vc2VybmFtZSBwYXNz d29yZCBhbmQgY29va2llcyBjb250aW51ZSB0byBiZSB3aWRlbHkgdXNlZCBpbiBwYXJ0IGJlY2F1 c2UgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGluIFRMUyBoYXMgbm90IGhhZCBhIGdvb2QgcnVuLjxz cGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5Zb3UgbWVhbiBiZWNhdXNlIGNsaWVudCBjZXJ0cyBhcmUgbm90IHdp ZGVseSBkZXBsb3llZCwgcmlnaHQ/wqAgUGVyaGFwcyBzb21lIG5hbWUvcGJrZGYyIGlzIGJldHRl cj8gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAvciQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPi0twqAgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPlByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ba2Ft YWkgVGVjaG5vbG9neTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5DYW1icmlkZ2UsIE1BPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvYm9keT48L2h0bWw+ --_000_2A0EFB9C05D0164E98F19BB0AF3708C711EFC3909CUSMBX1msgcorp_-- From nobody Mon Mar 3 19:53:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656301A0320 for ; Mon, 3 Mar 2014 19:53:10 -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, LOTS_OF_MONEY=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 WBdI-aUiVGUF for ; Mon, 3 Mar 2014 19:53:08 -0800 (PST) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 713031A031C for ; Mon, 3 Mar 2014 19:53:08 -0800 (PST) Received: by mail-yh0-f46.google.com with SMTP id v1so4465291yhn.33 for ; Mon, 03 Mar 2014 19:53: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=cEr5IHBHSd1+HZ4VLk/NW1lS2CL8taGO7uHn9xoGVH0=; b=GYQ8G8gvUgtI/iblTZpZbAh6h9H7Bnxldnhfy1692nOuHKhG2e1dFJGx/7JdYkzgno 3pwHp2HE7n2/AfkFCFWEV4hcnKtTioLqjO1YTwzf+Zyyo1F9Uae9Hs6VAZ/qH0K73Xrw f4xL6CpdiJRfAI1RkrX6dkxFrB0kAEQn4GEv+r4I8uPNsweMHFiIYc8ti1W77JFbxByz RWjwuolcNmH4S8P278Aay6Oo16ra2v7Wy7vyDflUy1xTwOKXrv9tylsTDnPXmSg+fZN1 EsI96fhtmCnfXnzp6j/Qc3ACFzb92AaYrloDpDpkLWj14UzK4aOC7bAa1btoeZJrrfG+ zRbw== MIME-Version: 1.0 X-Received: by 10.236.147.107 with SMTP id s71mr25129165yhj.45.1393905185178; Mon, 03 Mar 2014 19:53:05 -0800 (PST) Received: by 10.170.92.85 with HTTP; Mon, 3 Mar 2014 19:53:05 -0800 (PST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711EFC3909C@USMBX1.msg.corp.akamai.com> References: <5314AF9B.8000402@drh-consultancy.co.uk> <2A0EFB9C05D0164E98F19BB0AF3708C711EFC3909C@USMBX1.msg.corp.akamai.com> Date: Mon, 3 Mar 2014 19:53:05 -0800 Message-ID: From: Watson Ladd To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rwd9Fo8IpsIk97VkbwKycAjlLrE Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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: Tue, 04 Mar 2014 03:53:10 -0000 On Mon, Mar 3, 2014 at 3:32 PM, Salz, Rich wrote: >> both of which were previously noticed in 2009 with the Rex/Ray attack. > > Hmm=E2=80=A6 Four-plus years is a pretty darn good record, I=E2=80=99d s= ay. Protocols are not houses. They do not get mildew under the eves. Ants and termites do not eat the foundation. Unless you are an extreme intuitionist, TLS was as broken in 2009 as it was today. The pattern of decision making by this WG is clear: mistakes are noticed, and the fix doesn't actually cut to the core of the issue. This needs to end. I'll submit a TLS 2 draft that will be formally verified, easy to implement (modulo X509), and provide the secure channel semantics that TLS still doesn't. The big nonsecurity payoff: very few round trips. (1 if lucky, 2 if not) > >> why users should continue to trust TLS with confidential information. > > At the risk of being flip or snarky, because it=E2=80=99s the only thing = we have. > Therefore everyone uses it and therefore there are lots more =E2=80=9Cint= eresting=E2=80=9D > places for an adversary to attack. As the old joke goes, I don=E2=80=99t= have to > outrun the bear, I just have to outrun you. I'm not sure if that's comforting or alarming. As the old saying goes, if you don't know who the sucker is, it's you. That's why I never play poker thanks to application of Zorn's lemma. (Well, induction) > > At one point, the most common way banks transferred money amongst themsel= ves > was PGP signed data over FTP. I don=E2=80=99t know if it=E2=80=99s still = true. The US > Federal Reserve requires TLS over direct leased lines for banks doing > transactions more than $10Million. There's your answer: the Fed will not trust TLS with amounts over $10 million. Anyone here about to retire? My suggestion: call your broker and never use their website ever again. Because if the Fed gets robbed of $10 million they can print more. > >> Username password and cookies continue to be widely used in part because >> client authentication in TLS has not had a good run. > > You mean because client certs are not widely deployed, right? Perhaps so= me > name/pbkdf2 is better? The idea was that the browser would make certs and use them transparently: this was the idea behind Channel ID. But that got broken in this latest attack, unless you used ECDHE only. Password based derivations don't solve the phishing problem, unless you do something somewhat clever. (mix with hostname, then derive?) But thanks to backwards compat, a phisher can always get the password. Sincerely, Watson Ladd > > /r$ > > > > -- > > Principal Security Engineer > > Akamai Technology > > Cambridge, MA --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Mar 3 21:11:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D211A0359; Mon, 3 Mar 2014 21:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] 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 dGs3kgq8wSk9; Mon, 3 Mar 2014 21:11:39 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (unknown [69.163.253.163]) by ietfa.amsl.com (Postfix) with ESMTP id 47C771A0353; Mon, 3 Mar 2014 21:11:39 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id CEF1E594058; Mon, 3 Mar 2014 21:11:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=XQF+MXius5daosiIjXC9 P2VviNc=; b=uZb65MuRO0Nfyb3dC9sVS5iq8CqyhWooO4a+4fsEjJTKnwhE+PBv fX8XE9fTGSIp1mCh+gQiajn2A0R8TZThh1jQiJB6ZQiZoHweErzm9FQGTya+uyOi njXaue/ZNhK1o4USEb7O//2wYF2IuVh7bfITYRrx8k/JUBKxqcOFbpo= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 5A04C594055; Mon, 3 Mar 2014 21:11:35 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id u57so2473605wes.36 for ; Mon, 03 Mar 2014 21:11:34 -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=fMceg/6I3G79e6TQQMr4zUOAs0/ugwa2m2Ysj6UkeDo=; b=JstpNq1zucLpVqrNXG75dX/DW6//vweVg6CL6ONtBZG3h9A/UoTILpsW4k9kuPqQd4 RKTN+z0gGGis79V9zKtlMy4/r/Gr9cSuUf+a+QbeCHDFN0/QaJdsXgcJahk6hMffATMK Aa0Dcpv+WzW8mF1jvdzR+v7uAqFiQrqxcd2Ki6rBH+S2oE+3Ch13EDUplzZcO3f298Fk 2L6DPJ+tjTC50nJvzvLkigsZXeIc6KLHV6e5DYhZjzJmdkyENiGoXtKNrA6/WLON79SN kj7PobSLytKGCzt2sGeiMkB/tb92+AifN4Esq13TSZK1HfYMck1SCBpix5dYaN+G+v59 /ZAQ== MIME-Version: 1.0 X-Received: by 10.194.57.239 with SMTP id l15mr24212322wjq.40.1393909894084; Mon, 03 Mar 2014 21:11:34 -0800 (PST) Received: by 10.217.108.132 with HTTP; Mon, 3 Mar 2014 21:11:34 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Mar 2014 23:11:34 -0600 Message-ID: From: Nico Williams To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HBfSdxI6XqQxrIY6XpAneu247Ws Cc: "kitten@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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: Tue, 04 Mar 2014 05:11:44 -0000 [Cross-posting to kitten@ietf.org. Please drop one of tls or kitten when responding. For KITTEN readers, see the TLS list archives, there's an MITM vulnerability when using tls-unique in conjunction with session resumption.] On Mon, Mar 3, 2014 at 4:07 PM, Adam Langley wrote: > On Mon, Mar 3, 2014 at 4:07 PM, Andrei Popov wrote: >> It appears that the attack described is only feasible when two >> implementation defects are present: > > That's not an unreasonable characterisation of the renegotiation-based > attacks, but the problem with tls-unique is more fundamental. The problem for tls-unique is more fundamental indeed, and Andrei's characterization is not applicable. We should talk about how to fix tls-unique. The best fix may be to keep track of the original (non-resumed) connection's tls-unique CB and add that to the resumed connection's tls-unique CB. This requires adding to the session cache on the client side. In the short-term, client and server applications should not permit session resumption prior to channel-bound authentication (if using tls-unique). Except that, of course, how is the application to know if session resumption is involved? Assuming that it can't know or prevent the use of session resumption, I'd say that tls-unique is just simply not to be used. We should publish a new tls-unique that doesn't have this problem. Nico -- From nobody Mon Mar 3 23:03:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1361A03A3 for ; Mon, 3 Mar 2014 23:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_BACKHAIR_44=1, J_CHICKENPOX_46=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_56=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 2Pzpr_JhP87o for ; Mon, 3 Mar 2014 23:03:45 -0800 (PST) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5211A01AE for ; Mon, 3 Mar 2014 23:03:45 -0800 (PST) Received: by mail-yh0-f41.google.com with SMTP id f73so4696884yha.28 for ; Mon, 03 Mar 2014 23:03:42 -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=zxhC2/ykuNnzzYlieCzcpoK3Fw9egssrV17I3Nx6kTo=; b=tTByGK51A99798VpMAlSfzyODSMaepm0vq3AnhrCt6bTLdb69eQfcbL6KK1RWDdiro TMoikmAik2bQVuLgZbihDsMTwFJy3k8/muH9VmBLl6PU0woQt+fSusOajD/r1qaZ2LyA vCd7nMQ0pFqYHDesKLbffUCu64OnMEH3/FifmdEoKchKU3njWY/Rvic9efyRWcwMHSVP TQBaHd/jcDRH1ahLoEns/gyuMdmtaVuaHUkonGoGEAsNASpVe0PLdw0cI3/hOU2phTBT YPyhyLHxDd4vLoDqqZ3vbuOsg7+XufcUUhkGDBHC2Eoot4rZvtiyU0l3dD/TUbpglqu+ Ed8w== MIME-Version: 1.0 X-Received: by 10.236.24.196 with SMTP id x44mr6717795yhx.92.1393916621999; Mon, 03 Mar 2014 23:03:41 -0800 (PST) Received: by 10.170.92.85 with HTTP; Mon, 3 Mar 2014 23:03:41 -0800 (PST) In-Reply-To: References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com> <7A2637AF-5A16-404B-B7A1-49FB17D5345A@callas.org> Date: Mon, 3 Mar 2014 23:03:41 -0800 Message-ID: From: Watson Ladd To: Paul Lambert Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fDaiieXpXbzaMz4FEr-cG473oZc Cc: "cfrg@irtf.org" , Jon Callas , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Tue, 04 Mar 2014 07:03:47 -0000 On Mon, Mar 3, 2014 at 9:32 PM, Paul Lambert wrote: > > > On 3/3/14, 2:52 PM, "Jon Callas" wrote: > >>On Mar 2, 2014, at 3:40 PM, Paul Lambert wrote: >> >>> Implementations are possible by using the readily available open source >>> implementation. This is a good thing, but it is also desirable >>> to have a unambiguous description of the algorithms that is not >>> a C code file. This is why we write RFCs... >> >>It's hard to disagree with this, in a similar way that it's hard to >>disagree with the idea of peace on earth, living at one with nature, etc. >> >>But in practice, code needs to be in a computer language rather than >>English and I've seen (and been involved with) a document that started >>with rough consensus and running code, translated that into English, and >>the English was (and is) devilishly hard to compile back into C. > Yes - I=C2=B9e seen the same problem. English is not a concise or clear = way to > document an algorithm. Really? Because all the people doing algorithms I've seen use English to describe their results because it is clearer then code. For instance, consider the following short C code. typedef struct{ member *p; int rank} member; void init(member *a){a->p=3Da; rank=3D0;} member * find(member *a){ member *q=3Da; member *r=3DNULL; member *t; while(q !=3Dq->p){ t=3Dq->p; q->p=3Dr; r=3Dq; q=3Dt; } while (r !=3DNULL){ t=3Dr->p; r->p=3Dq; r=3Dt; } return q; } void union(member *a, member *b){ a=3Dfind(a); b=3Dfind(b); if(a->rankrank){ a->p=3Db->p; b->rank++; } else { b->p=3Da->p; a->rank++; } } The above code is of course union-find. However, I don't know what looking at the above code tells you about the algorithm. By contrast the following description gets the point across much more clearly. "We consider a forest where the root node of each tree points to itself, and pointers point up. The find operation takes the node it is given, and follows the chain of pointers to the root, reversing each pointer. It then descends the chain, setting each encountered pointer to the root. The union operation links the root with lower rank to the one with greater rank and increments the rank of the new root." In particular the description makes clear the invariant that is maintained: each set has a unique element that points to itself, the rank of a node is an upper bound on the height of the tree rooted at that node. The code makes none of this clear: it is concerned entirely with bookkeeping that seems as important as the main idea. For something like F5, or point counting, or inverse square root, or direct sparse matrix factoring, or the Fast Fourier Transform, the gap between what English is able to do and what an executable representation can do in terms of ideas is only bigger. There is a reason computer science produces books, not code. > > HAC is pretty clear and is a decent example of cryptographic algorithm > descriptions (http://cacr.uwaterloo.ca/hac/about/chap8.pdf), but still > uses a mix of math notation and english text. Your use of the word "still" implies that you think the two are in some way opposed. They aren't: programming languages have nowhere near the capacity of expressing ideas that the English language does. >> >>Portably implemented algorithms are hard to do in any computer language. >>They're harder to do in words. I don't see how you're going to get an >>unambiguous description of the language in anything but a computer >>language. It doesn't have to be C, it could be Python, Ruby, or Algol-58 >>(which I mention because it was originally designed as an algorithmic >>description language). English is a suboptimal implementation language. > > Yes, exactly! 'Readable code=C2=B9 would be a very good way to provide = an > algorithm description. Why bother with pseudo code when a executable > syntax could be used. I submitted earlier on this list some Python code > fragments as examples of this approach. Python allows operator > overloading, so it can provide some very readable ECC algorithm > descriptions. Readable without a working Python implementation to see what happens? Note that Python code implementing Curve25519 exists in "Cryptography in NaCl", which also contains test vectors. Does anyone have an objection to putting equivalent Python in the draft/would this satisfy those calling for more documentation? If I have the nroff source of the draft I can do it in a few hours. Sincerely, Watson Ladd > > Paul > > > > >> >> Jon >> > --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Mar 3 23:18:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1209A1A036C; Mon, 3 Mar 2014 21:33:08 -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, 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 k6RlryHj7wcn; Mon, 3 Mar 2014 21:33:06 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id B97AA1A0366; Mon, 3 Mar 2014 21:33:06 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s245Wu0d011203; Mon, 3 Mar 2014 21:32:57 -0800 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1jcrfcv5m0-27 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 03 Mar 2014 21:32:57 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Mon, 3 Mar 2014 21:32:52 -0800 From: Paul Lambert To: Jon Callas Date: Mon, 3 Mar 2014 21:32:52 -0800 Thread-Topic: [Cfrg] Citing specs in specs Thread-Index: Ac83ay/UcpeQCEuqTpurMCDpBspGng== Message-ID: References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com> <7A2637AF-5A16-404B-B7A1-49FB17D5345A@callas.org> In-Reply-To: <7A2637AF-5A16-404B-B7A1-49FB17D5345A@callas.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-04_02:2014-03-03,2014-03-04,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403030212 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SGupovuGD_BCYsESeMcJUjg-gv4 X-Mailman-Approved-At: Mon, 03 Mar 2014 23:18:37 -0800 Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Tue, 04 Mar 2014 05:33:08 -0000 On 3/3/14, 2:52 PM, "Jon Callas" wrote: >On Mar 2, 2014, at 3:40 PM, Paul Lambert wrote: > >> Implementations are possible by using the readily available open source >> implementation. This is a good thing, but it is also desirable >> to have a unambiguous description of the algorithms that is not >> a C code file. This is why we write RFCs... > >It's hard to disagree with this, in a similar way that it's hard to >disagree with the idea of peace on earth, living at one with nature, etc. > >But in practice, code needs to be in a computer language rather than >English and I've seen (and been involved with) a document that started >with rough consensus and running code, translated that into English, and >the English was (and is) devilishly hard to compile back into C. Yes - I=B9e seen the same problem. English is not a concise or clear way t= o document an algorithm. HAC is pretty clear and is a decent example of cryptographic algorithm descriptions (http://cacr.uwaterloo.ca/hac/about/chap8.pdf), but still uses a mix of math notation and english text. > >Portably implemented algorithms are hard to do in any computer language. >They're harder to do in words. I don't see how you're going to get an >unambiguous description of the language in anything but a computer >language. It doesn't have to be C, it could be Python, Ruby, or Algol-58 >(which I mention because it was originally designed as an algorithmic >description language). English is a suboptimal implementation language. Yes, exactly! 'Readable code=B9 would be a very good way to provide an algorithm description. Why bother with pseudo code when a executable syntax could be used. I submitted earlier on this list some Python code fragments as examples of this approach. Python allows operator overloading, so it can provide some very readable ECC algorithm descriptions. Paul > > Jon > From nobody Tue Mar 4 02:58:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACCB1A02CE; Tue, 4 Mar 2014 02:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.833 X-Spam-Level: * X-Spam-Status: No, score=1.833 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_BACKHAIR_44=1, J_CHICKENPOX_46=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=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 meVzC-Dg5FaN; Tue, 4 Mar 2014 02:58:16 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id F2A8A1A06D6; Tue, 4 Mar 2014 02:58:15 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s24Aw1GW022475; Tue, 4 Mar 2014 02:58:01 -0800 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0b-0016f401.pphosted.com with ESMTP id 1jcrfcw98c-17 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 04 Mar 2014 02:58:01 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::4561:8e1c:d59b:f770%17]) with mapi; Tue, 4 Mar 2014 02:58:00 -0800 From: Paul Lambert To: Watson Ladd Date: Tue, 4 Mar 2014 02:57:58 -0800 Thread-Topic: [Cfrg] Citing specs in specs Thread-Index: Ac83mJvkWMeWwwBDQkKRJ68Rj1zacg== Message-ID: References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com> <7A2637AF-5A16-404B-B7A1-49FB17D5345A@callas.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-04_04:2014-03-04,2014-03-04,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403040016 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/upXfIBJs1BzqlOLK1z5JaCAAB0U Cc: "cfrg@irtf.org" , Jon Callas , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Tue, 04 Mar 2014 10:58:18 -0000 DQoNCk9uIDMvNC8xNCwgMzowMyBQTSwgIldhdHNvbiBMYWRkIiA8d2F0c29uYmxhZGRAZ21haWwu Y29tPiB3cm90ZToNCg0KPk9uIE1vbiwgTWFyIDMsIDIwMTQgYXQgOTozMiBQTSwgUGF1bCBMYW1i ZXJ0IDxwYXVsQG1hcnZlbGwuY29tPiB3cm90ZToNCj4+DQo+Pg0KPj4gT24gMy8zLzE0LCAyOjUy IFBNLCAiSm9uIENhbGxhcyIgPGpvbkBjYWxsYXMub3JnPiB3cm90ZToNCj4+DQo+Pj5PbiBNYXIg MiwgMjAxNCwgYXQgMzo0MCBQTSwgUGF1bCBMYW1iZXJ0IDxwYXVsQG1hcnZlbGwuY29tPiB3cm90 ZToNCj4+Pg0KPj4+PiBJbXBsZW1lbnRhdGlvbnMgYXJlIHBvc3NpYmxlIGJ5IHVzaW5nIHRoZSBy ZWFkaWx5IGF2YWlsYWJsZSBvcGVuDQo+Pj4+c291cmNlDQo+Pj4+IGltcGxlbWVudGF0aW9uLiAg VGhpcyBpcyBhIGdvb2QgdGhpbmcsIGJ1dCBpdCBpcyBhbHNvIGRlc2lyYWJsZQ0KPj4+PiB0byBo YXZlIGEgdW5hbWJpZ3VvdXMgZGVzY3JpcHRpb24gb2YgdGhlIGFsZ29yaXRobXMgdGhhdCBpcyBu b3QNCj4+Pj4gYSBDIGNvZGUgZmlsZS4gIFRoaXMgaXMgd2h5IHdlIHdyaXRlIFJGQ3MuLi4NCj4+ Pg0KPj4+SXQncyBoYXJkIHRvIGRpc2FncmVlIHdpdGggdGhpcywgaW4gYSBzaW1pbGFyIHdheSB0 aGF0IGl0J3MgaGFyZCB0bw0KPj4+ZGlzYWdyZWUgd2l0aCB0aGUgaWRlYSBvZiBwZWFjZSBvbiBl YXJ0aCwgbGl2aW5nIGF0IG9uZSB3aXRoIG5hdHVyZSwNCj4+PmV0Yy4NCj4+Pg0KPj4+QnV0IGlu IHByYWN0aWNlLCBjb2RlIG5lZWRzIHRvIGJlIGluIGEgY29tcHV0ZXIgbGFuZ3VhZ2UgcmF0aGVy IHRoYW4NCj4+PkVuZ2xpc2ggYW5kIEkndmUgc2VlbiAoYW5kIGJlZW4gaW52b2x2ZWQgd2l0aCkg YSBkb2N1bWVudCB0aGF0IHN0YXJ0ZWQNCj4+PndpdGggcm91Z2ggY29uc2Vuc3VzIGFuZCBydW5u aW5nIGNvZGUsIHRyYW5zbGF0ZWQgdGhhdCBpbnRvIEVuZ2xpc2gsIGFuZA0KPj4+dGhlIEVuZ2xp c2ggd2FzIChhbmQgaXMpIGRldmlsaXNobHkgaGFyZCB0byBjb21waWxlIGJhY2sgaW50byBDLg0K Pj4gWWVzIC0gSan2ZSBzZWVuIHRoZSBzYW1lIHByb2JsZW0uICBFbmdsaXNoIGlzIG5vdCBhIGNv bmNpc2Ugb3IgY2xlYXIgd2F5DQo+PnRvDQo+PiBkb2N1bWVudCBhbiBhbGdvcml0aG0uDQo+DQo+ UmVhbGx5PyBCZWNhdXNlIGFsbCB0aGUgcGVvcGxlIGRvaW5nIGFsZ29yaXRobXMgSSd2ZSBzZWVu IHVzZSBFbmdsaXNoDQo+dG8gZGVzY3JpYmUgdGhlaXIgcmVzdWx0cyBiZWNhdXNlIGl0IGlzIGNs ZWFyZXIgdGhlbiBjb2RlLg0KPg0KPkZvciBpbnN0YW5jZSwgY29uc2lkZXIgdGhlIGZvbGxvd2lu ZyBzaG9ydCBDIGNvZGUuDQoNCg0KTm8gSSB3aWxsIG5vdC4gIFJlYWQgbXkgc3VnZ2VzdGlvbiAt IEMgY29kZSBzdWNrcyBmb3IgcmVhZGFiaWxpdHkuICBZZXMgLQ0KRW5nbGlzaCBpcyBhbHdheXMg bmVlZGVkLCBldmVuIGluIGNvZGUgZm9yIGNvbW1lbnRzLg0KDQpQc2V1ZG8gY29kZSBpcyBqdXN0 IKGucHN1ZWRvoa8gYW5kIGxhY2tzIGRlZmluZWQgc3ludGF4LiAgSGlnaGVyIGxldmVsDQpsYW5n dWFnZXMgbGlrZSBQeXRob24gb3IgUnVieSBwcm92aWRlIGFuIG9wcG9ydHVuaXR5IGZvciBjbGVh ciBhbmQNCnN5bnRhY3RpY2FsbHkgd2VsbCBkZWZpbmVkIGFsZ29yaXRobSBkZWZpbml0aW9ucy4g IFNwZWNpZmljYWxseSB3aGVyZSB3ZQ0KYXJlIGRlc2NyaWJpbmcgZXF1YXRpb25zIGZvciB0aGlu Z3MgbGlrZSAtIGl0ZXJhdGluZyBvdmVyIGEgcmFuZ2UsDQpyZWN1cnNpdmUgYWxnb3JpdGhtcywg ZXRjLiAgRXhhbXBsZXMgd291bGQgbG9vayBsaWtlOg0KDQpkZWYgYWRkX3BvaW50cyhjdXJ2ZSwg cDEsIHAyKToNCiAgICAiIiIgQWRkIHR3byBwb2ludHMgb24gdGhlIGN1cnZlICIiIg0KICAgIHgx ID0gcDEueDsgIHgyID0gcDIueDsgIHkxID0gcDEueTsgIHkyID0gcDIueQ0KICAgIGQgPSBjdXJ2 ZS5kOyBhID0gY3VydmUuYTsgcCA9IGN1cnZlLnA7IGludiA9IGN1cnZlLmludmVyc2UNCiAgICAg ICAgDQogICAgIyBFZHdhcmRzIGN1cnZlIGFkZGl0aW9uDQogICAgeDMgPSAoICh4MSp5Mit4Mip5 MSkgKiBpbnYoMStkKngxKngyKnkxKnkyKSApICUgcA0KICAgIHkzID0gKCAoeTEqeTItYSp4MSp4 MikgKiBpbnYoMS1kKngxKngyKnkxKnkyKSApICUgcA0KICAgIHJldHVybiBjdXJ2ZS5wb2ludCh4 MywgeTMpDQoNCiNvcg0KDQpjbGFzcyBDdXJ2ZTI1NTE5KCBNb250Z29tZXJ5Q3VydmVGcCApOg0K ICAgICIiIiB5KioyID09IHgqKjMgKyA0ODY2NjIqeCoqMiArIHggIG1vZCAyKioyNTUtMTkgIiIi DQogICAgY3VydmVJZCA9ICdjdXJ2ZTI1NTE5Jw0KICAgIHN0cmVuZ3RoID0gMTI2DQogICAgb2lk ID0gTm9uZQ0KICAgIHAgID0gMioqMjU1LTE5DQogICAgYSAgPSA0ODY2NjINCiAgICB4RyA9IDkN CiAgICB5RyA9ICANCjB4MjBhZTE5YTFiOGEwODZiNGUwMWVkZDJjNzc0OGQxNGM5MjNkNGQ3ZTZk N2M2MWIyMjllOWM1YTI3ZWNlZDNkOQ0KICAgIG4gID0gMioqMjUyICsgMjc3NDIzMTc3NzczNzIz NTM1MzU4NTE5Mzc3OTA4ODM2NDg0OTMNCiAgICBoICA9IDgNCg0KDQoNCllvdXIgZXhhbXBsZSBi ZWxvdyBpcyBpcnJlbGV2YW50IGFuZCBJoa9tIG5vdCBzdXJlIHdoeSB5b3UgYXJlIGFsd2F5cw0K ZGlzYWdyZWVpbmcgd2l0aCBhbnl0aGluZyBhbnlvbmUgcG9zdHMgb24gdGhlIGxpc3QuDQoNCg0K DQoNCj4NCj50eXBlZGVmIHN0cnVjdHsgbWVtYmVyICpwOyBpbnQgcmFua30gbWVtYmVyOw0KPg0K PnZvaWQgaW5pdChtZW1iZXIgKmEpe2EtPnA9YTsgcmFuaz0wO30NCj4NCj5tZW1iZXIgKiBmaW5k KG1lbWJlciAqYSl7DQo+ICAgbWVtYmVyICpxPWE7DQo+ICAgbWVtYmVyICpyPU5VTEw7DQo+ICAg bWVtYmVyICp0Ow0KPiAgIHdoaWxlKHEgIT1xLT5wKXsNCj4gICAgICAgICAgICB0PXEtPnA7DQo+ ICAgICAgICAgICAgcS0+cD1yOw0KPiAgICAgICAgICAgIHI9cTsNCj4gICAgICAgICAgICBxPXQ7 DQo+ICAgIH0NCj4gd2hpbGUgKHIgIT1OVUxMKXsNCj4gICAgICAgICB0PXItPnA7DQo+ICAgICAg ICAgci0+cD1xOw0KPiAgICAgICAgcj10Ow0KPiAgfQ0KPnJldHVybiBxOw0KPn0NCj4NCj52b2lk IHVuaW9uKG1lbWJlciAqYSwgbWVtYmVyICpiKXsNCj4gICBhPWZpbmQoYSk7DQo+ICAgYj1maW5k KGIpOw0KPiAgIGlmKGEtPnJhbms8Yi0+cmFuayl7DQo+ICAgICAgICAgIGEtPnA9Yi0+cDsNCj4g ICAgICAgICAgYi0+cmFuaysrOw0KPiAgICB9IGVsc2Ugew0KPiAgICAgICBiLT5wPWEtPnA7DQo+ ICAgICAgYS0+cmFuaysrOw0KPiAgIH0NCj59DQo+DQo+VGhlIGFib3ZlIGNvZGUgaXMgb2YgY291 cnNlIHVuaW9uLWZpbmQuIEhvd2V2ZXIsIEkgZG9uJ3Qga25vdyB3aGF0DQo+bG9va2luZyBhdCB0 aGUgYWJvdmUgY29kZSB0ZWxscyB5b3UgYWJvdXQgdGhlIGFsZ29yaXRobS4gQnkgY29udHJhc3QN Cj50aGUgZm9sbG93aW5nIGRlc2NyaXB0aW9uIGdldHMgdGhlIHBvaW50IGFjcm9zcyBtdWNoIG1v cmUgY2xlYXJseS4NCj4iV2UgY29uc2lkZXIgYSBmb3Jlc3Qgd2hlcmUgdGhlIHJvb3Qgbm9kZSBv ZiBlYWNoIHRyZWUgcG9pbnRzIHRvDQo+aXRzZWxmLCBhbmQgcG9pbnRlcnMgcG9pbnQgdXAuIFRo ZSBmaW5kIG9wZXJhdGlvbiB0YWtlcyB0aGUgbm9kZSBpdCBpcw0KPmdpdmVuLCBhbmQgZm9sbG93 cyB0aGUgY2hhaW4gb2YgcG9pbnRlcnMgdG8gdGhlIHJvb3QsIHJldmVyc2luZyBlYWNoDQo+cG9p bnRlci4gSXQgdGhlbiBkZXNjZW5kcyB0aGUgY2hhaW4sIHNldHRpbmcgZWFjaCBlbmNvdW50ZXJl ZCBwb2ludGVyDQo+dG8gdGhlIHJvb3QuIFRoZSB1bmlvbiBvcGVyYXRpb24gbGlua3MgdGhlIHJv b3Qgd2l0aCBsb3dlciByYW5rIHRvIHRoZQ0KPm9uZSB3aXRoIGdyZWF0ZXIgcmFuayBhbmQgaW5j cmVtZW50cyB0aGUgcmFuayBvZiB0aGUgbmV3IHJvb3QuIg0KPg0KPkluIHBhcnRpY3VsYXIgdGhl IGRlc2NyaXB0aW9uIG1ha2VzIGNsZWFyIHRoZSBpbnZhcmlhbnQgdGhhdCBpcw0KPm1haW50YWlu ZWQ6IGVhY2ggc2V0IGhhcyBhIHVuaXF1ZSBlbGVtZW50IHRoYXQgcG9pbnRzIHRvIGl0c2VsZiwg dGhlDQo+cmFuayBvZiBhIG5vZGUgaXMgYW4gdXBwZXIgYm91bmQgb24gdGhlIGhlaWdodCBvZiB0 aGUgdHJlZSByb290ZWQgYXQNCj50aGF0IG5vZGUuIFRoZSBjb2RlIG1ha2VzIG5vbmUgb2YgdGhp cyBjbGVhcjogaXQgaXMgY29uY2VybmVkIGVudGlyZWx5DQo+d2l0aCBib29ra2VlcGluZyB0aGF0 IHNlZW1zIGFzIGltcG9ydGFudCBhcyB0aGUgbWFpbiBpZGVhLg0KPg0KPkZvciBzb21ldGhpbmcg bGlrZSBGNSwgb3IgcG9pbnQgY291bnRpbmcsIG9yIGludmVyc2Ugc3F1YXJlIHJvb3QsIG9yDQo+ ZGlyZWN0IHNwYXJzZSBtYXRyaXggZmFjdG9yaW5nLCBvciB0aGUgRmFzdCBGb3VyaWVyIFRyYW5z Zm9ybSwgdGhlIGdhcA0KPmJldHdlZW4gd2hhdCBFbmdsaXNoIGlzIGFibGUgdG8gZG8gYW5kIHdo YXQgYW4gZXhlY3V0YWJsZQ0KPnJlcHJlc2VudGF0aW9uIGNhbiBkbyBpbiB0ZXJtcyBvZiBpZGVh cyBpcyBvbmx5IGJpZ2dlci4gVGhlcmUgaXMgYQ0KPnJlYXNvbiBjb21wdXRlciBzY2llbmNlIHBy b2R1Y2VzIGJvb2tzLCBub3QgY29kZS4NCj4NCj4+DQo+PiBIQUMgaXMgcHJldHR5IGNsZWFyIGFu ZCBpcyBhIGRlY2VudCBleGFtcGxlIG9mIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtDQo+PiBkZXNj cmlwdGlvbnMgKGh0dHA6Ly9jYWNyLnV3YXRlcmxvby5jYS9oYWMvYWJvdXQvY2hhcDgucGRmKSwg YnV0IHN0aWxsDQo+PiB1c2VzIGEgbWl4IG9mIG1hdGggbm90YXRpb24gYW5kIGVuZ2xpc2ggdGV4 dC4NCj4NCj5Zb3VyIHVzZSBvZiB0aGUgd29yZCAic3RpbGwiIGltcGxpZXMgdGhhdCB5b3UgdGhp bmsgdGhlIHR3byBhcmUgaW4NCj5zb21lIHdheSBvcHBvc2VkLiBUaGV5IGFyZW4ndDogcHJvZ3Jh bW1pbmcgbGFuZ3VhZ2VzIGhhdmUgbm93aGVyZSBuZWFyDQo+dGhlIGNhcGFjaXR5IG9mIGV4cHJl c3NpbmcgaWRlYXMgdGhhdCB0aGUgRW5nbGlzaCBsYW5ndWFnZSBkb2VzLg0KDQpZZXMgLSBib3Ro IGFyZSByZXF1aXJlZC4NCj4NCj4+Pg0KPj4+UG9ydGFibHkgaW1wbGVtZW50ZWQgYWxnb3JpdGht cyBhcmUgaGFyZCB0byBkbyBpbiBhbnkgY29tcHV0ZXIgbGFuZ3VhZ2UuDQo+Pj5UaGV5J3JlIGhh cmRlciB0byBkbyBpbiB3b3Jkcy4gSSBkb24ndCBzZWUgaG93IHlvdSdyZSBnb2luZyB0byBnZXQg YW4NCj4+PnVuYW1iaWd1b3VzIGRlc2NyaXB0aW9uIG9mIHRoZSBsYW5ndWFnZSBpbiBhbnl0aGlu ZyBidXQgYSBjb21wdXRlcg0KPj4+bGFuZ3VhZ2UuIEl0IGRvZXNuJ3QgaGF2ZSB0byBiZSBDLCBp dCBjb3VsZCBiZSBQeXRob24sIFJ1YnksIG9yIEFsZ29sLTU4DQo+Pj4od2hpY2ggSSBtZW50aW9u IGJlY2F1c2UgaXQgd2FzIG9yaWdpbmFsbHkgZGVzaWduZWQgYXMgYW4gYWxnb3JpdGhtaWMNCj4+ PmRlc2NyaXB0aW9uIGxhbmd1YWdlKS4gRW5nbGlzaCBpcyBhIHN1Ym9wdGltYWwgaW1wbGVtZW50 YXRpb24gbGFuZ3VhZ2UuDQo+Pg0KPj4gWWVzLCBleGFjdGx5ISAgICdSZWFkYWJsZSBjb2RlqfYg d291bGQgYmUgYSB2ZXJ5IGdvb2Qgd2F5IHRvIHByb3ZpZGUgYW4NCj4+IGFsZ29yaXRobSBkZXNj cmlwdGlvbi4gIFdoeSBib3RoZXIgd2l0aCBwc2V1ZG8gY29kZSB3aGVuIGEgZXhlY3V0YWJsZQ0K Pj4gc3ludGF4IGNvdWxkIGJlIHVzZWQuICAgSSBzdWJtaXR0ZWQgZWFybGllciBvbiB0aGlzIGxp c3Qgc29tZSBQeXRob24NCj4+Y29kZQ0KPj4gZnJhZ21lbnRzIGFzIGV4YW1wbGVzIG9mIHRoaXMg YXBwcm9hY2guICBQeXRob24gYWxsb3dzIG9wZXJhdG9yDQo+PiBvdmVybG9hZGluZywgc28gaXQg Y2FuIHByb3ZpZGUgc29tZSB2ZXJ5IHJlYWRhYmxlIEVDQyBhbGdvcml0aG0NCj4+IGRlc2NyaXB0 aW9ucy4NCj4NCj5SZWFkYWJsZSB3aXRob3V0IGEgd29ya2luZyBQeXRob24gaW1wbGVtZW50YXRp b24gdG8gc2VlIHdoYXQgaGFwcGVucz8NCj4NCj5Ob3RlIHRoYXQgUHl0aG9uIGNvZGUgaW1wbGVt ZW50aW5nIEN1cnZlMjU1MTkgZXhpc3RzIGluICJDcnlwdG9ncmFwaHkNCj5pbiBOYUNsIiwgd2hp Y2ggYWxzbyBjb250YWlucyB0ZXN0IHZlY3RvcnMuDQoNClBpZWNlcyBvZiB0aGUgY29kZSByZWFk IHdlbGwgoaYgdGhlIGNvZGUgYnkgaXShr3Mgc2VsZiBpcyBub3QgYQ0Kc3BlY2lmaWNhdGlvbi4N ClRoZSChrmFkZKGvIGNvZGUgaXMgYSBnb29kIGV4YW1wbGUgb2Ygc29tZXRoaW5nIHRoYXQgY291 bGQgYmUgdXNlZDoNCg0KDQpkZWYgYWRkKCh4bix6biksICh4bSx6bSksICh4ZCx6ZCkpOg0KICAg IHggPSA0ICogKHhtICogeG4gLSB6bSAqIHpuKSAqKiAyICogemQNCiAgICB6ID0gNCAqICh4bSAq IHpuIC0gem0gKiB4bikgKiogMiAqIHhkDQogICAgcmV0dXJuICh4ICUgUCwgeiAlIFApDQoNCg0K DQo+RG9lcyBhbnlvbmUgaGF2ZSBhbiBvYmplY3Rpb24gdG8gcHV0dGluZyBlcXVpdmFsZW50IFB5 dGhvbiBpbiB0aGUNCj5kcmFmdC93b3VsZCB0aGlzIHNhdGlzZnkgdGhvc2UgY2FsbGluZyBmb3Ig bW9yZSBkb2N1bWVudGF0aW9uPw0KPklmIEkgaGF2ZSB0aGUgbnJvZmYgc291cmNlIG9mIHRoZSBk cmFmdCBJIGNhbiBkbyBpdCBpbiBhIGZldyBob3Vycy4NCg0Koa5yZWFkYWJsZScgY29kZSB3cml0 dGVuIHRvIGNsb3NlbHkgbWFwIHRvIHRoZSBhbGdvcml0aG0gZGVzY3JpcHRpb24NCndvdWxkIGJl IGdvb2QgLSBidXQgdGhpcyBpcyBub3QgYSByYXcgbnJvZmYgb2YgdGhlIHNvdXJjZSBmaWxlLg0K SaGvbSBzdWdnZXN0aW5nIHRoYXQgd2hhdCBpcyBuZWVkZWQgaXMgYSBkb2N1bWVudCB1c2luZyBl bmdsaXNoIHRleHQNCmluIHRoZSBzdHlsZSBvZjoNCiBodHRwOi8vd3d3Lm5zYS5nb3YvaWEvX2Zp bGVzL25pc3Qtcm91dGluZXMucGRmDQpXaGVyZSB0aGUgcHN1ZWRvIGNvZGUgaXMgcmVwbGFjZWQg d2l0aCByZWFsIFB5dGhvbiBmdW5jdGlvbnMuDQoNClRoYXQgc2FpZCChpiB5b3VyIGZsaXAgYW5k IG5lZ2F0aXZlIGNvbW1lbnRzIGFyZSB2ZXJ5IGZydXN0cmF0aW5nIHRvIGRlYWwNCndpdGggYW5k IGl0oa9zIG5vdCBhIGdvb2Qgd2F5IHRvIGdldCBhbnkgY29uc2Vuc3VzLiAgVGhlIG5vdGUgd2Fz IGFsc28gbm90DQpkaXJlY3RlZCB0byB5b3UgYW5kIEkgZG8gbm90IGV4cGVjdCB5b3UgdGFrZSBh bnkgYWN0aW9uIGZyb20gdGhpcw0Kc3VnZ2VzdGlvbi4gIEmhr20gaG9waW5nIG90aGVycyB3aWxs IGNhcnJ5IHRoZSBmbGFnIGZvciB0aGlzIGRvY3VtZW50YXRpb24NCmV4ZXJjaXNlIGFuZCB0aGF0 IHRoZXkgd2lsbCBiZSBlYXNpZXIgdG8gY29tbXVuaWNhdGUgd2l0aCBvbiB0aGUgbWFpbGluZw0K bGlzdC4NCg0KDQpQYXVsDQoNCg0KDQoNCj4NCj5TaW5jZXJlbHksDQo+V2F0c29uIExhZGQNCj4+ DQo+PiBQYXVsDQo+Pg0KPj4NCj4+DQo+Pg0KPj4+DQo+Pj4gICAgICAgSm9uDQo+Pj4NCj4+DQo+ DQo+DQo+DQo+LS0gDQo+IlRob3NlIHdobyB3b3VsZCBnaXZlIHVwIEVzc2VudGlhbCBMaWJlcnR5 IHRvIHB1cmNoYXNlIGEgbGl0dGxlDQo+VGVtcG9yYXJ5IFNhZmV0eSBkZXNlcnZlIG5laXRoZXIg IExpYmVydHkgbm9yIFNhZmV0eS4iDQo+LS0gQmVuamFtaW4gRnJhbmtsaW4NCg0K From nobody Tue Mar 4 06:03:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1414B1A0176 for ; Tue, 4 Mar 2014 06:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hb0B3pSOCrn6 for ; Tue, 4 Mar 2014 06:03:25 -0800 (PST) Received: from claranet-outbound-smtp06.uk.clara.net (claranet-outbound-smtp06.uk.clara.net [195.8.89.39]) by ietfa.amsl.com (Postfix) with ESMTP id AFE421A0206 for ; Tue, 4 Mar 2014 06:03:24 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:50437 helo=[192.168.7.9]) by relay16.mail.eu.clara.net (relay.clara.net [81.171.239.36]:10465) with esmtpa (authdaemon_plain:drh) id 1WKpwF-0001dX-MZ for tls@ietf.org (return-path ); Tue, 04 Mar 2014 14:03:20 +0000 Message-ID: <5315DD23.30901@drh-consultancy.co.uk> Date: Tue, 04 Mar 2014 14:03:15 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> In-Reply-To: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zm-tWplZrQd3V5QcDlwybTJe0b8 Subject: Re: [TLS] MITM Attacks on Client Authentication after 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: Tue, 04 Mar 2014 14:03:28 -0000 On 03/03/2014 19:37, Martin Rex wrote: > Dr Stephen Henson wrote: >> >> If the client checks the hostname against the certificate whenever a >> certificate is presented[2] then additionally the attacker needs a certificate >> with the same hostname as the attacked server. >> >> 2. This isn't always the case. Some applications check the hostname only after >> the handshake has completed. > > An application client that is using a TLS library _without_ callbacks, > and requests a blocking TLS handshake to be performed, will only get to > see the server certificate after the handshake has completed. > > While the X.509 cert chain validation might be performed in-band > by the TLS stack, the rfc2818 Section 3.1 server endpoint > identification is left up to the application caller. > A stack might have an option to check the hostname as part of the in-band cert validation and, on failure, abort the handshake at that point just like any other validation error. For example OpenSSL 1.0.2 can do that but previous versions do not. Since that's an unreleased version it's likely no existing clients use that option. I performed a few checks with an experimental option to change the server certificate during renegotiation, which I believe simulates the attack mechanism. If the client checks certificates in band then all versions choke with a verification error if a chain is untrusted. For 1.0.2 only it also chokes if the chain is trusted but the hostname doesn't match. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nobody Tue Mar 4 07:23:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25AB51A0085 for ; Tue, 4 Mar 2014 07:23: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 RPSkki9pgfCJ for ; Tue, 4 Mar 2014 07:23:45 -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 6EC151A007C for ; Tue, 4 Mar 2014 07:23:45 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id q58so4976566wes.26 for ; Tue, 04 Mar 2014 07:23: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=kjHdu+OQGHuNk7NckAHC1sweg/X9LYANj6yZ2suOLBw=; b=0BqlbN0jHmQvMXy+XhM4ER1CYMgYaYAZX/pJEIxUlyQLuzxLpv7d2qtLlQoe9Xti/I ZX15SWEf0pKeROYiNulb+RExQWLJgNu87S5EUkTNYK0eJql3zqE30RwDp2moiff0hOiO 6pmMapw2IrMYYxJFvAT0rgbMkJlReDUlM9tMAW3ONlhQRWWJKTZg4kxkaI2xVMUyV3eu Spp7N8Zp9MrjwYxke6f52Vw48dvmNaElV9tmje89ysHlBQiUMqdS3AjNQqM9jKho3Xs2 b0NBM1EVABzwL7neIGiaht0X8RqQU6xnJEu3jdtxTptntarzEJiNBfInh37Vk2DDYmnM 0s6w== MIME-Version: 1.0 X-Received: by 10.194.170.167 with SMTP id an7mr14522wjc.39.1393946621776; Tue, 04 Mar 2014 07:23:41 -0800 (PST) Received: by 10.227.10.196 with HTTP; Tue, 4 Mar 2014 07:23:41 -0800 (PST) In-Reply-To: <5315DD23.30901@drh-consultancy.co.uk> References: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> <5315DD23.30901@drh-consultancy.co.uk> Date: Tue, 4 Mar 2014 15:23:41 +0000 Message-ID: From: Martin Thomson To: Dr Stephen Henson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qZNS9AxykwwxiLdw-pl46tqEi8k Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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: Tue, 04 Mar 2014 15:23:47 -0000 On 4 March 2014 14:03, Dr Stephen Henson wrote: > > I performed a few checks with an experimental option to change the server > certificate during renegotiation, which I believe simulates the attack > mechanism. If the client checks certificates in band then all versions choke > with a verification error if a chain is untrusted. For 1.0.2 only it also chokes > if the chain is trusted but the hostname doesn't match. This is an interesting option. I like the general idea, but wonder what "hostname doesn't match" means in this case. To provide some context, in HTTP/2 we are considering having multiple names share the same connection, as long as they are covered by wildcards or additional subjectAltName values. You might start out looking for "foo.example.com", but as long as you have "*.example.com" or "bar.example.com" in subjectAltName, you will proceed with requests to "bar.example.com" on that connection. I think that it would be unlikely that a renegotiated certificate would include some names from a previous certificate, but not others, but that might be a problem if an implementation fixates on a single name. From nobody Tue Mar 4 08:05:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07F31A01A8 for ; Tue, 4 Mar 2014 08:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5OQ_cKSZLFR for ; Tue, 4 Mar 2014 08:05:49 -0800 (PST) Received: from claranet-outbound-smtp01.uk.clara.net (claranet-outbound-smtp01.uk.clara.net [195.8.89.34]) by ietfa.amsl.com (Postfix) with ESMTP id BBCB31A00F5 for ; Tue, 4 Mar 2014 08:05:22 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:45878 helo=[192.168.7.9]) by relay11.mail.eu.clara.net (relay.clara.net [81.171.239.31]:10465) with esmtpa (authdaemon_plain:drh) id 1WKrqI-0005Fc-3Z (return-path ); Tue, 04 Mar 2014 16:05:18 +0000 Message-ID: <5315F9BA.4060805@drh-consultancy.co.uk> Date: Tue, 04 Mar 2014 16:05:14 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Thomson References: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> <5315DD23.30901@drh-consultancy.co.uk> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sR4T8Shts_e1dk-STBgKTbf5dtE Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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: Tue, 04 Mar 2014 16:05:51 -0000 On 04/03/2014 15:23, Martin Thomson wrote: > On 4 March 2014 14:03, Dr Stephen Henson wrote: >> >> I performed a few checks with an experimental option to change the server >> certificate during renegotiation, which I believe simulates the attack >> mechanism. If the client checks certificates in band then all versions choke >> with a verification error if a chain is untrusted. For 1.0.2 only it also chokes >> if the chain is trusted but the hostname doesn't match. > > This is an interesting option. I like the general idea, but wonder > what "hostname doesn't match" means in this case. > > To provide some context, in HTTP/2 we are considering having multiple > names share the same connection, as long as they are covered by > wildcards or additional subjectAltName values. You might start out > looking for "foo.example.com", but as long as you have "*.example.com" > or "bar.example.com" in subjectAltName, you will proceed with requests > to "bar.example.com" on that connection. > > I think that it would be unlikely that a renegotiated certificate > would include some names from a previous certificate, but not others, > but that might be a problem if an implementation fixates on a single > name. > Well in the specific case of OpenSSL a hostname is supplied via the API and that is checked against the server certificate whenever it is presented. So it would allow the certificate to change but an attacker would need a trusted certificate matching the server's hostname. If they have that they can MITM the server (provided it doesn't support client authentication) anyway. It has been suggested that clients could be stricter and prohibit changes of server certificate during renegotiation entirely, if not outright at least by default. I'd be interested if anyone knows of examples where the server certificate does have to change during renegotiation and how common that practice is. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nobody Tue Mar 4 08:11:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670F41A00B9 for ; Tue, 4 Mar 2014 08:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 g5NfkiwYOMCu for ; Tue, 4 Mar 2014 08:11:43 -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 6E2A51A0194 for ; Tue, 4 Mar 2014 08:11:34 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id cz12so6047695veb.30 for ; Tue, 04 Mar 2014 08:11:31 -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=Zpx4YsUIFCQsxED3VySzytLC8PRva2McKke/2qVsWes=; b=jWLAAGaZAkl5ul8/p/Ho2O/EeW4qf8ldBAqBs29Qa7Hv7HYnqb29mZSRlDws3ko3MX l0kL5WwutEKpB6hqwbBXD3V/9x4qxjzOvWoCW8B3fppvWgYNI6adCYf0V6A72mhg8wIo j+uK3uNrrmtu2xHMvrtQ8KJzNVzMCMg4mU88o3iPra/4636XPu3IdItCoC0MOYm/44Me msbUhP4LUhYljYUYHfPCDkQbDGYaTOLiFRHSfRq1IU1onncks45jOhv2Z18hCmtY2sbG 2CK8iBUYXOBdHDIG9FAlHiqmE5xDumNi2y6yGTQDWwt/fs2200Vd2u47+wTYkGgAuhW9 Sd7A== 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=Zpx4YsUIFCQsxED3VySzytLC8PRva2McKke/2qVsWes=; b=kdz0BfgSIM5LhHffJgfOmJ6RiU5brGQ1jADERNv7lmlJV7R08RDsZ5nUY0uKZgzDHH W83zWNLFFk9nVUfzNLTumSGPMSaYlxjym65ow3UbuclnvphjYFzQy6KX2RrLkSPuFDkC eD9vopP61UgDuSMa2CVuLoX2gwYcz9KE2v7cCWsJT6rGzQIl9vHwoHw4r3+uIq9pBiPt MdSXaPtsUVNsIXPsZDLJrnKJkb1Err7W15yR+sBLrnrGXxAO6qIKIRxMcQuBbdLKUYKx Glqgs7tlK5GkD0x1lhiSy+ud8h0i+wDWwrDrlKAjGEMROzBAy5/lz6bDghI8odCFMmJh ukHg== X-Gm-Message-State: ALoCoQlL8ugql7oXc59LEm/bwgMzqtJG0HD2Wif/h7pOixRgZLsIlz4OSAObAUb7HtYHKGPRodvpBb9GBiLCZ57R/5ppIgcuHHNwOD77jX+UtJIJz133wIQ+x9aJvLGT6FNtHsLzWJIBtcn+6nnEfv+YfH9I7/pYBacraFHNWNuEXJhTSLxGs9cFFTWC65Z0Kv8ZDs0/9Og9 X-Received: by 10.58.200.229 with SMTP id jv5mr151942vec.15.1393949490629; Tue, 04 Mar 2014 08:11:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Tue, 4 Mar 2014 08:11:10 -0800 (PST) In-Reply-To: <5315F9BA.4060805@drh-consultancy.co.uk> References: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> <5315DD23.30901@drh-consultancy.co.uk> <5315F9BA.4060805@drh-consultancy.co.uk> From: Adam Langley Date: Tue, 4 Mar 2014 11:11:10 -0500 Message-ID: To: Dr Stephen Henson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-dR-f8P_t9ty0fJhHCcvjhzsnkg Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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: Tue, 04 Mar 2014 16:11:50 -0000 On Tue, Mar 4, 2014 at 11:05 AM, Dr Stephen Henson wrote: > I'd be interested if anyone knows of examples where the server certificate does > have to change during renegotiation and how common that practice is. Chrome outright rejects renegotiations where the leaf certificate changes and we've had no reported issues. Cheers AGL From nobody Tue Mar 4 08:53:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9B01A01CD for ; Tue, 4 Mar 2014 08:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 VjiFMwtHUl1l for ; Tue, 4 Mar 2014 08:53:44 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0CADF1A0191 for ; Tue, 4 Mar 2014 08:53:44 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:45644 helo=dhcp-a575.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WKsbC-000JSu-2L; Tue, 04 Mar 2014 11:53:46 -0500 Message-ID: <53160513.20703@bbn.com> Date: Tue, 04 Mar 2014 11:53:39 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: tls@ietf.org, Steve Kent Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aoA4Cd_YzocYFO6iHM_u3Y1dLhU Subject: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 16:53:46 -0000 For those who did not attend or remotely participate in the TLS WG meeting on 3/4/14, EKR suggested that I draw your attention to the slides I presented. The focus of my presentation was a suggestion that ChaCha, when its used as a cipher suite for DTLS, use an explicit IV for the per-packet unique value, not re-use the DTLS record number (to save space). I reviewed several reasons for this, based on discussions that took place in the IPsec WG several years ago, when we considered the same topic for AES counter mode use with ESP. We decided to require each packet to carry an IV independent of the ESP sequence number (or extended sequence number). Slide 5 of my presentation enumerates reasons for not re-using a packet/record sequence number for an IV. I also noted (Slide 3) that the proposal to use ChaCha with ESP follows the approach we have adopted for other algorithms, and thus it is preferable that DTLS use the same approach, to enable common hardware and software implementations to support both protocols. Steve From nobody Tue Mar 4 08:57:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57F91A00BB for ; Tue, 4 Mar 2014 08:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 A-92RghcUh-G for ; Tue, 4 Mar 2014 08:57:39 -0800 (PST) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 404171A01A8 for ; Tue, 4 Mar 2014 08:57:38 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id oy12so3902407veb.18 for ; Tue, 04 Mar 2014 08:57:34 -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=cRd3xwCEzSRsBdFZ/a4tfiDZupN5TCLyZlyAjzwxekU=; b=HbbVT6ejaq5gvgGZt0MnppN2wjUlZ4yOn9i/Y6lULj19DNwVdfhpWtBfl2nKHE4LD3 VAWsqP0vnRUL/MzwLSFAgyRwk3W2hhjSfi6cqbSKUIatAcQeRkDpZ8jbXW1kgzY2L61E KupYbex9mVruAvQK7H/vFj0+o95VOMR9ZwX2L77CCoz7e46eaZ99XO59jkHABlGQ+9b3 2QbervWcxAciBeFASqVtB+/vNWB7elONptLHbZ0FQJM+YgCHRrhtM2iDV3Scne0FrdV5 TFxuJMFKaecGMfu3lOKhFLqAjsvp7JftQIabDG42bRcFLZQPXviLxrGbnBtdmgEfw9sQ sodw== 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=cRd3xwCEzSRsBdFZ/a4tfiDZupN5TCLyZlyAjzwxekU=; b=RibBSsiim4TZ4SOACSqfIej/CkKnhizSWNw1WgX+OPN6ZbhYeBMxFOmZ/HjjVLjq3S K3rybxo7bWhp9uYuv/mdS0VeMNRA7vV9gFyH7q78l5I/gzGLXnVnSdPTLzrq4xyFUaCC Y2/oWphaqH0WDLajgCDwolR7mmsjSQQUWJyxZ9RpaFwx+EC/kfSmAKvQfIkEBbsTV3c8 M9ZSFHvFbFmsB4mLHZqv3TuPVF+3fcCWsGwKe3HQ/92uJceKtvFEkzxdHxtbTcDom/Pt o/t4bnXzb+14vLCMA24O6Oy0DPnDzAJMsC4we4flrTJilJ7FzdUW4YLMC7diGm8YYkAq idew== X-Gm-Message-State: ALoCoQm7W2T93uwH6+3nwFb5HFu4AReHL8v5Lfc9IplfYPJB5YYxKsulYdyPciS6utd8rfDtxTJDlrAOwxYhfKDkqNcWMpbc49MPLcKoEcrW7LGsPPtiHPokRnMOwmKRVXQWZNfhsN7HamONDoGO1Se9v2jrMSj+0E62zxYTkCd0O9DySj172x/Sj4U1D8TF4F9rjG4RKm8w X-Received: by 10.221.30.14 with SMTP id sa14mr363766vcb.44.1393952254747; Tue, 04 Mar 2014 08:57:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Tue, 4 Mar 2014 08:57:13 -0800 (PST) In-Reply-To: <53160513.20703@bbn.com> References: <53160513.20703@bbn.com> From: Adam Langley Date: Tue, 4 Mar 2014 11:57:13 -0500 Message-ID: To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vojbv7fL_rxDtt644NT4cpJ8AVs Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 16:57:41 -0000 On Tue, Mar 4, 2014 at 11:53 AM, Stephen Kent wrote: > For those who did not attend or remotely participate in the TLS WG meeting > on 3/4/14, EKR suggested that I draw your attention to the slides I > presented. Are the slides available anywhere? Cheers AGL From nobody Tue Mar 4 08:58:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A321A00BB for ; Tue, 4 Mar 2014 08:58: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 XLli91_9LtCd for ; Tue, 4 Mar 2014 08:58:22 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D48361A0202 for ; Tue, 4 Mar 2014 08:58:21 -0800 (PST) Received: by mail-yk0-f173.google.com with SMTP id 10so14922486ykt.4 for ; Tue, 04 Mar 2014 08:58: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=ZfyWJPg13nipsOMOKsU22xYenNhKz6AkNdxYc/KWLBM=; b=aKPjR/lQ4otZGIpAah6EjvnNyfo94i4B1+zctrb1RcAB6DOx+hsy59ejEIgho+/nWH xQn6Vy+BrUsYRTslT7F7jOhwCt0nEeEcM+0Ao/kiu55exe/FcqxoQ/BpsuEloaveqkxa LSb9wrJIwevjNDn2QZNl4pCTLGOgmBq8MiiB15WhNb+Io7rLyaxWbUmZAQeUjG5P9euz HB3O82GJ5aHRp6GJrP01g6b4yGLsEUJuUanAo/emgJ+FB3+l0btYOchA5b7saAHST+9x 8lo9MMbBb2R/DCusbzzkEZCuM/9a2AhkpPXEzdOwsXzvi5J16Ts8AowB0/9MMdMnYh7y GI/Q== MIME-Version: 1.0 X-Received: by 10.236.216.106 with SMTP id f100mr506435yhp.129.1393952298405; Tue, 04 Mar 2014 08:58:18 -0800 (PST) Received: by 10.170.92.85 with HTTP; Tue, 4 Mar 2014 08:58:18 -0800 (PST) In-Reply-To: References: <53160513.20703@bbn.com> Date: Tue, 4 Mar 2014 08:58:18 -0800 Message-ID: From: Watson Ladd To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4f1HKuJzQA08UhNQEH7s1lEchX4 Cc: Stephen Kent , "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 16:58:28 -0000 http://www.ietf.org/proceedings/89/slides/slides-89-tls-2.pdf On Tue, Mar 4, 2014 at 8:57 AM, Adam Langley wrote: > On Tue, Mar 4, 2014 at 11:53 AM, Stephen Kent wrote: >> For those who did not attend or remotely participate in the TLS WG meeting >> on 3/4/14, EKR suggested that I draw your attention to the slides I >> presented. > > Are the slides available anywhere? > > > Cheers > > AGL > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue Mar 4 09:03:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD1A1A020B for ; Tue, 4 Mar 2014 09:02: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 ju22eS95be98 for ; Tue, 4 Mar 2014 09:02:39 -0800 (PST) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 217F11A01D9 for ; Tue, 4 Mar 2014 09:02:39 -0800 (PST) Received: by mail-yh0-f45.google.com with SMTP id i57so5133941yha.4 for ; Tue, 04 Mar 2014 09:02:35 -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=js/tZT83Kp50kv+NtDxPp0VwBHnfHeLkG2VY0uImDvc=; b=0eFJUVwwHtMZrnhPLvWJ+iFcay38xYiEEqZXu9nMlCVsKBEwfAt/gRza7i8VaeLgMA Ige/1n9P6iFeTgBRUHN1g2WHoPYxmJfCMnqjs63caxDXXwAn59zeC//OGeOH+3ta9A7+ qCB5EMv3yrGfyITZIaViFvw5KH6izeWA37tQ14uKw1HhuMoQo78h/YhqcqbSD0rgemXu +3lz5MAFRiIQ4LCqkJTXibaC85MbETNgB9g3CEKpaVQexIT5LdOxMdr9qcS7HLwWS7oT WVXEpcoDhKVvTvSPfjO3j8hCkS2KF4f2sqQoCYb80M1sXbcteIMrdoPb9dqM54rl22ws jV5w== MIME-Version: 1.0 X-Received: by 10.236.32.36 with SMTP id n24mr730122yha.116.1393952555792; Tue, 04 Mar 2014 09:02:35 -0800 (PST) Received: by 10.170.92.85 with HTTP; Tue, 4 Mar 2014 09:02:35 -0800 (PST) In-Reply-To: References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com> <7A2637AF-5A16-404B-B7A1-49FB17D5345A@callas.org> Date: Tue, 4 Mar 2014 09:02:35 -0800 Message-ID: From: Watson Ladd To: Paul Lambert Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cyO3zmDn0l7etCWEzPqEBe4NInc Cc: "cfrg@irtf.org" , Jon Callas , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Tue, 04 Mar 2014 17:02:42 -0000 X-List-Received-Date: Tue, 04 Mar 2014 17:02:42 -0000 Dear all, This is provisionally my last word on the matter. Any consensus based process only works if people will block a largely formed consensus for a good reason only. A document being unclear, or having unanalyzed security properties, or major issues with regards to alternatives not being discussed are good reasons. But the argument that Paul I think is making, that until the CFRG produces a draft ala RFC 6090 for Edwards curve we cannot use them, is fundamentally unconvincing. First off, let me note that black box implementations of Curve25519 using the paper are possible: I've written them, Adam Langley has written them, as have lots of other people. So that leaves the argument that the implementations require too much knowledge about cryptography, and that such an issue is worth blocking specs. The simplest argument for why it is unconvincing is the date of RFC 6090 vs. the dates of protocols that included Suite B and ECC. RFC 4869 includes Suite B a full 4 years before RFC 6090 was published. Now, it is possible that Paul's argument was valid, but simply wasn't raised at the time RFC 4869 was being published. But I don't see any evidence that implementors of RFC 4869 were hamstrung by the nonexistence of RFC 6090. The second reason I am unconvinced is that I don't see why we shouldn't assume the availability of standard references such as the Handbook Of Elliptic and Hyperelliptic Curve Cryptography, or volume 2 of Knuth, to implementors. Such documents are available for far less money than ISO standards, and in many regions of North America, Europe and Asia, can be found for free in the library. The goal of a spec is to explain to humans what is to be done: including excessive information makes this much harder. Finally, Mr. Lambert writes in terms of the "onus" being on CFRG to produce such a document, which he calls a "usable normative reference". Such a bare assertion is entirely unconvincing. Furthermore, CFRG owes Paul nothing. While I would be happy to review such a document for accuracy, I have no obligation to review or produce such a document, and the same holds for all the members of the CFRG. I can just as easily say that Mr. Lambert has the onus to produce such a document. I've changed my mind about the desirability of such a document as Mr. Lambert wants. It would be nice if it existed, and it would be a nice project to learn CWEB. However, I see no reason to consider the absence of such a document a good reason to block draft-josefsson-tls-curve25519-04. Sincerely, Watson Ladd From nobody Tue Mar 4 09:57:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DA11A024A for ; Tue, 4 Mar 2014 09:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 dZCiorxqv7rX for ; Tue, 4 Mar 2014 09:57:29 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 99D8E1A0262 for ; Tue, 4 Mar 2014 09:57:29 -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 s24HvM3s030026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Mar 2014 12:57:23 -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 s24HvJ86014067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 4 Mar 2014 12:57:21 -0500 Message-ID: <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Stephen Kent Date: Tue, 04 Mar 2014 18:57:19 +0100 In-Reply-To: <53160513.20703@bbn.com> References: <53160513.20703@bbn.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.22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QZQiguMlpc5FPJl5EQt5ilEoahw Cc: tls@ietf.org Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 17:57:32 -0000 On Tue, 2014-03-04 at 11:53 -0500, Stephen Kent wrote: > I reviewed several reasons for this, based on discussions that took place in > the IPsec WG several years ago, when we considered the same topic for > AES counter > mode use with ESP. We decided to require each packet to carry an IV > independent of > the ESP sequence number (or extended sequence number). Slide 5 of my > presentation > enumerates reasons for not re-using a packet/record sequence number for > an IV. Hello, I believe there advantages in using the record sequence number for an IV _in TLS_, but before mentioning them, I'll make some comments on your points. > From a security assurance perspective, an IV based on a > protocol-supplied value expands the scope of what has to > be analyzed (to ensure uniqueness) In TLS the record sequence numbers are unique by definition, thus any analysis is simplified. > An algorithm implementation submitted for FIPS evaluation > must be independently evaluable >From the wording I don't understand how this is relevant to your point for nonces. Could you elaborate? > If DTLS and ESP adopt different IV approaches for the > same algorithm/mode, chip vendors have problems By problems I suppose that you mean that they have to implement a module that works with both. > In some cases, a non-counter IV approach can be faster > than a counter (in hardware) I don't think that this is a good argument against implicit nonces. In software the counter IV approach is always faster. > Allowing each sender to choose its own IV generation > approach is more flexible Indeed, but flexibility in security protocols isn't an advantage, and I don't see what is the actual gain from such flexibility. So now for the arguments for using the record sequence number as (part of) the nonce in TLS: * It reduces the exchanged data (by 12 or 8 bytes - depending on the explicit nonce size). This is particularly important in DTLS where the typical record size is less than 1400 bytes. * It ensures that the nonce is unique even until 2^64-1 records are exchanged (which is the termination limit for TLS sessions). regards, Nikos From nobody Tue Mar 4 10:15:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF941A027D for ; Tue, 4 Mar 2014 10:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 mO7RoHfWzw9C for ; Tue, 4 Mar 2014 10:15:06 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4B71A0187 for ; Tue, 4 Mar 2014 10:15:06 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:43482 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WKtrp-000Ir6-Ls; Tue, 04 Mar 2014 13:15:01 -0500 Message-ID: <53161825.7060409@bbn.com> Date: Tue, 04 Mar 2014 13:15:01 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Uhu4P9-lwuVzVB-vBRmn8pfvKTc Cc: tls@ietf.org Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 18:15:09 -0000 Nikos, >> I reviewed several reasons for this, based on discussions that took place in >> the IPsec WG several years ago, when we considered the same topic for >> AES counter >> mode use with ESP. We decided to require each packet to carry an IV >> independent of >> the ESP sequence number (or extended sequence number). Slide 5 of my >> presentation >> enumerates reasons for not re-using a packet/record sequence number for >> an IV. > Hello, > I believe there advantages in using the record sequence number for an > IV _in TLS_, but before mentioning them, I'll make some comments on your > points. > >> From a security assurance perspective, an IV based on a >> protocol-supplied value expands the scope of what has to >> be analyzed (to ensure uniqueness) > In TLS the record sequence numbers are unique by definition, thus any > analysis is simplified. Security evaluation for a crypto alg does not include a protocol like ESP or (D)TLS; if focuses only on the alg implementation. Thus a TLS "guarantee" of uniqueness is not relevant. Anyone who has had a product evaluated will tell you that the goal is always to minimize the amount of code that is subject to review. If one were to use a TLS (or ESP) sequence number for an IV, all of the protocol code would be part of the evaluation, and that would make the evaluation prolonged and very costly. > >> An algorithm implementation submitted for FIPS evaluation >> must be independently evaluable > >From the wording I don't understand how this is relevant to your point > for nonces. Could you elaborate? As noted above, if one submits an implementation of AES (or, maybe later, ChaCha) for evaluation by NIST or a NIST-certified lab, the alg implementation is evaluated by itself, independent of any protocol. if you look at the FIPS 140-x list of evaluated products you'll see that they are evaluated wrt crypto security, not wrt a protocol that uses the crypto. This is true even if a product is a crypto accelerator for IPsec or TLS. > >> If DTLS and ESP adopt different IV approaches for the >> same algorithm/mode, chip vendors have problems > By problems I suppose that you mean that they have to implement a module > that works with both. yes. > >> In some cases, a non-counter IV approach can be faster >> than a counter (in hardware) > I don't think that this is a good argument against implicit nonces. In > software the counter IV approach is always faster. yes, but software is not the only game in town. If thousands of sessions terminate at a collection of servers it has been common practice to use hardware to offload the processing from the servers. This also affords better protection to the traffic keys. >> Allowing each sender to choose its own IV generation >> approach is more flexible > Indeed, but flexibility in security protocols isn't an advantage, and I > don't see what is the actual gain from such flexibility. In this case the flexibility is desirable because it allows different implementations to decide how to manage the IVs, as senders, without the need to coordinate with receivers. > So now for the arguments for using the record sequence number as (part > of) the nonce in TLS: > * It reduces the exchanged data (by 12 or 8 bytes - depending on the > explicit nonce size). This is particularly important in DTLS where the > typical record size is less than 1400 bytes. The typical packet size in the ESP context is at least that small. > * It ensures that the nonce is unique even until 2^64-1 records are > exchanged (which is the termination limit for TLS sessions). this guarantee is only as good as the assurance of the TLS code than manages the sequence numbers, which is not likely to be secure as the alg implementation. Steve From nobody Tue Mar 4 10:18:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81571A02E4 for ; Tue, 4 Mar 2014 10:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t5ueHyOoXQh for ; Tue, 4 Mar 2014 10:18:28 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 74D6B1A02B5 for ; Tue, 4 Mar 2014 10:18:28 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BCD4647417; Tue, 4 Mar 2014 18:18:24 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id B11AD47414; Tue, 4 Mar 2014 18:18:24 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id A60E2FE298; Tue, 4 Mar 2014 18:18:24 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Tue, 4 Mar 2014 13:18:24 -0500 From: "Salz, Rich" To: Nikos Mavrogiannopoulos , Stephen Kent Date: Tue, 4 Mar 2014 13:18:22 -0500 Thread-Topic: [TLS] ChaCha and IVs Thread-Index: Ac830zpnMxDih95KRT676jhllNGkWQAArapw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711EFC393FA@USMBX1.msg.corp.akamai.com> References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ohUmOE6MX_0KyhhTCLPnccOYPBE Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 18:18:30 -0000 > In TLS the record sequence numbers are unique by definition, thus any ana= lysis is simplified. Ever done a FIPS or similar certification? You have to give them your sour= ce code. You really don't want to require the TLS stack to be included in = that bundle when all you want is certified crypto. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, M From nobody Tue Mar 4 10:30:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A65A1A02CE for ; Tue, 4 Mar 2014 10:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i7zqp7Pt8sw for ; Tue, 4 Mar 2014 10:30:13 -0800 (PST) Received: from claranet-outbound-smtp08.uk.clara.net (claranet-outbound-smtp08.uk.clara.net [195.8.89.41]) by ietfa.amsl.com (Postfix) with ESMTP id BA56A1A01F1 for ; Tue, 4 Mar 2014 10:30:11 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:12056 helo=[192.168.7.9]) by relay18.mail.eu.clara.net (relay.clara.net [81.171.239.38]:10465) with esmtpa (authdaemon_plain:drh) id 1WKu6N-0001v4-S5 for tls@ietf.org (return-path ); Tue, 04 Mar 2014 18:30:03 +0000 Message-ID: <53161BA7.3070405@drh-consultancy.co.uk> Date: Tue, 04 Mar 2014 18:29:59 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TGA3gngMcdCZdAE4Fj_RdX3ueD8 Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 18:30:16 -0000 On 04/03/2014 17:57, Nikos Mavrogiannopoulos wrote: > On Tue, 2014-03-04 at 11:53 -0500, Stephen Kent wrote: > >> An algorithm implementation submitted for FIPS evaluation >> must be independently evaluable > >>From the wording I don't understand how this is relevant to your point > for nonces. Could you elaborate? > In the case of AES-GCM there are some requirements for how the IV is generated for FIPS (and FIPS 140-2) compliance. It has been a while since I looked at this in detail but from memory it effectively meant the explicit part of the IV had to be generated by the module itself on encrypt (various schemes were permissible). An application couldn't specify an arbitrary value which would seem to preclude the use of the sequence number directly. So on encrypt you'd typically call the module to generate the explicit part of the IV and then use that generated value in the protocol (for TLS copy it to the explicit IV part of the record). Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nobody Tue Mar 4 10:30:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F7D1A01F1 for ; Tue, 4 Mar 2014 10:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 DHiKBn2Y6rKn for ; Tue, 4 Mar 2014 10:30:25 -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 334F01A02D5 for ; Tue, 4 Mar 2014 10:30:23 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id cz12so6231956veb.30 for ; Tue, 04 Mar 2014 10:30:19 -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=TNz1hVbvgqJbGu59LseVp1lV/1J9nvelYN9zdkf6Mwk=; b=cDXC7Agf3pHZWfpYXw2Bt8HSoJhCW3RgmnupsvwVCeBUhYdPLpb4lBy6hpdhq2dfEK BOOCY6kCsvgdlGrC/lxUaEm8lmlQ6wJ6hYAXK7EKLOC6ZzC2GQS7BC2vaKlQTh7Q68rs ldm18VizCWar69lTu6HuHG4RRM3HZt1R5IeDDVmXw70gIGQsnRQZTGwV8lbv7XfUKubs jp+IU+nOWo4vsreeD1tIatvD7RIPPv691XZM/A4LlYpNYJrGapvCDhQVWQtlT7LB3H/U 0/FPHVkK3kodkms0ZvvRmCWgxEU0DAouWrj6GXOQUjnlB2svjjMBWmljCBcq9/8Wm1cP 3/mA== 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=TNz1hVbvgqJbGu59LseVp1lV/1J9nvelYN9zdkf6Mwk=; b=BnX4WEh/6oZGvwvq7HnIDTgc0694AaBHoNK05eHGCBs1O6SxjTRjVlWNUgAe/Rup6a NFIgVMZa+AwXDFU52Tnxb6YgsHUoHeywYHSdQXtspd6iyKtLMnW/rK+a6C+8zJ5rJDWX b9QK03VeoZS8v/pHjytamjI+2v0ixD/mVgzhrGI+V7r0hAahbjGkb+TOhvU4iJxUcUsg PdUzgU7814JtTSXo/Q9yrX3nncr37Ru9O2l2ztUcCX2uZu/Qql/yLzlEF6vFrnhYpcKA F1sZBgKo6iDNY3TFaszyRMKYswVVyS7HuqVBZrP6wBGl7vO/zLo1PxMrLID4cAW27Iw+ FLnQ== X-Gm-Message-State: ALoCoQl+LQruiwAeY4C2+xUaqT0zlbJnTyhIFycUj91ci2yt5tSbkMEKlm8bb4g2Hf9/9FQtt2cTbzPy3ivOesYDGxQN9Nbw88G8TumWrmG3IpsMpJIE5XKb/P/c7ivQRu4PhknxBVZ8YqmIXsWex6jKiR1fNgqA1diUkb/LIce5fBefbQz+zK2xM710yONtWeck4GDP8TZy X-Received: by 10.58.200.168 with SMTP id jt8mr700373vec.30.1393957518135; Tue, 04 Mar 2014 10:25:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Tue, 4 Mar 2014 10:24:57 -0800 (PST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711EFC393FA@USMBX1.msg.corp.akamai.com> References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C711EFC393FA@USMBX1.msg.corp.akamai.com> From: Adam Langley Date: Tue, 4 Mar 2014 13:24:57 -0500 Message-ID: To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Y3IeK0dofnMmNQDNzLvwLWIhZuc Cc: Stephen Kent , "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 18:30:29 -0000 On Tue, Mar 4, 2014 at 1:18 PM, Salz, Rich wrote: > Ever done a FIPS or similar certification? You have to give them your source code. You really don't want to require the TLS stack to be included in that bundle when all you want is certified crypto. If you wish to certify an AEAD you only need to provide the code for an AEAD. The nonce input is well specified and has uniqueness requirements. In the same way, the key in a traditional cipher also has uniqueness requirements, but I don't believe that the full TLS key-agreement needs to be included. Cheers AGL From nobody Tue Mar 4 10:48:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C191A0290 for ; Tue, 4 Mar 2014 10:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 GAW0Xhpb0jcZ for ; Tue, 4 Mar 2014 10:48:05 -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 C00DC1A0187 for ; Tue, 4 Mar 2014 10:48:04 -0800 (PST) Received: by mail-ve0-f179.google.com with SMTP id db12so6091629veb.24 for ; Tue, 04 Mar 2014 10:48:01 -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=1Hs8wviczvPf50f8P0P5reM7GaV06hV9JdMAnIEKARw=; b=omXGnJHXD3UhPaS/e720UZ2vuVuWpsVW1WVObhjGgHusRSBnoTMdjM2sv6xmuwoVo7 7FzujT0IHZOy8N2ci52+7RZWuH8b8twVr7pid5++Ad2j+J486rfepRUh5DioxUwxgZ4X Kn+ekcVSikC/d/wmXVBTnoJ4EkSc0UA/P4sEstjjl2bYf1CRD9wr3g+Dw9p1MkF+Smar nRouYbzpj7E8oCxzl/fCe6gqppHqhcBIYn/4v5WRAWjWD/Jv6+k+Wu0zX6r70IhuIKgt P+8+PsBpo14nCmlNYe6gs0AoN1qPBf2NzIz42YpghhjmKXx7WRl66zx7HS+MubhFpt+N UeeQ== 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=1Hs8wviczvPf50f8P0P5reM7GaV06hV9JdMAnIEKARw=; b=UFStn0yVvgSAyGQhHcfU5x8vKu/kECUyarW5t/19wuBtD9yQzWw1O1yCvVrsZQLlOQ 14T3rOFfABi6JcE5ClJWYI6Hd3uuOh4uvemAcpu4crRwQJr+kz3XN9DzKAUJIg15Fl+X UKIt89ytG/kpjXFL7dMpaXP0+toR+4oaYa1TVOXxAb/Jh8qa65GGl/hz/DPN2PYizOC5 INjm5jIcw5DMyFYsyulFaMgi1FNKqqjAHpMy8fquR1wUyIeG1eG+UpXD0zfr/Zu7VsDS 7KvSMoLBoUyNzN7EcOugw82PzHmYXEuzFhUIefiiG0jZO8e4DpB1nJJ0QtaqGTEabNse zS6g== X-Gm-Message-State: ALoCoQnodocS31A6tmF+pmVXGRKIV5uj16kEH058QFOW+/gniyOtUJH3nN2xZOqK09gBLky+i8cdsWFokIR+BGk+CxQpHzmimA6M+wQenrgB7hoD1K7ZzU6G1LK5xsZooBiciOeTbbDTuQzZxm/xvD5hMPbcBOSZxcMtGsMZvAU123nuaienMlY9+U07xHrDOsviNyD10KDQ X-Received: by 10.58.54.35 with SMTP id g3mr653746vep.46.1393957049726; Tue, 04 Mar 2014 10:17:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Tue, 4 Mar 2014 10:17:09 -0800 (PST) In-Reply-To: <53160513.20703@bbn.com> References: <53160513.20703@bbn.com> From: Adam Langley Date: Tue, 4 Mar 2014 13:17:09 -0500 Message-ID: To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/a3OAXTQ9r4LKc7xqwZ4Rz8fKJHg Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 18:48:07 -0000 Here are the points from the slides: > From a security assurance perspective, > an IV based on a protocol-supplied value > expands the scope of what has to be > analyzed (to ensure uniqueness) The uniqueness of the sequence number is needed to ensure that records cannot be reordered so you cannot get away from having to establish that property. > An algorithm implementation submitted for FIPS evaluation must be independently evaluable. An evaluation already assumes properties - i.e. that the key is actually secret! The interface and assumptions of an AEAD are well established (https://tools.ietf.org/html/rfc5116) and include an nonce input that must be unique for a given key. > If DTLS and ESP adopt different IV approaches for the > same algorithm/mode, chip vendors have problems ChaCha is not the hardware orientated cipher in any case, but I'm unconvinced this is true. So far, hardware implementations that I've seen take the nonce as an input, which is also the obvious design from my point of view. > In some cases, a non-counter IV approach can be faster > than a counter (in hardware) A non-counter IV is not safe unless the nonce is significantly extended. Certainly, nobody should never use a non-counter IV with AES-GCM in TLS. In any case, I think significant evidence would be needed to show that the performance of this outweighs the cost of wasting ~16 bytes / record. > Allowing each sender to choose its own IV generation > approach is more flexible. It's flexible in the same way that AES-GCM in TLS is flexible: i.e. that I had to survey all the implementations to ensure that nobody has used a random IV because that's unsafe. I don't want that sort of flexibility! Cheers AGL From nobody Tue Mar 4 10:57:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352491A017B for ; Tue, 4 Mar 2014 10:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 O2GiXdYkN4xo for ; Tue, 4 Mar 2014 10:56:56 -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 BAC231A02D5 for ; Tue, 4 Mar 2014 10:56:55 -0800 (PST) Received: by mail-ve0-f179.google.com with SMTP id db12so6194894veb.38 for ; Tue, 04 Mar 2014 10:56:52 -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=7wp8VtEnAtTMPEXUyRC0LUZJpG4evBfT+EvHS2LJirA=; b=WWb2AR6elThnOdyKFpOgVv6SWcqG4Qe693bSzz2qxuxFoUXwJhWeldEVPGBsP6F/r1 2yjTp+6XpcekCJ/KnKfkX+uTG9SS0CJqEvbcng3ny4SrSkESWfwyUbwxsfUo82QLBt+q cZpQDhJXkrNiGS8GG5kLusx6fQ3DPKusCNiyk0nNIl9Uf0CQYqudh0WEuOKqieR+5IRX WR9Y/tROjXNndZDSCGGFYlptvtvfmVek2UEu8e56yrOSYtX8m0obTNJOfDb/EHQzJ8VE RfbNaZfG6N/74OvhPbmJieOpC+IcU/MdhvVTIX+jB7aWXWYBSyI2A5tHy2n4brUN1RFv h58g== 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=7wp8VtEnAtTMPEXUyRC0LUZJpG4evBfT+EvHS2LJirA=; b=GjoGt1mwrddaathMuPQ5CQB9Iy58/gqXYzgkkrhU5URMcJYdilTBU1E2YnX2rPoTlN 8b6/0ZYPzKyQH3aYq6/Gs0U0t4l6yFOGSnulJfx/xWAOPz6z23wvWYttlS/dZBVOQAVJ dc6WylTTtIxwqp7JQ33Jt4CO8GLqX6g6ZJu2jyX4JqeRFfcln6bji4LtcTZkoM5UQmiY Ffiwyq1ZdEAEyR6h551HnqP0nGZYGoiuf3V1oCKfkJzC/tM3+Be6cn4ieqGm5si+vugs tbgdG6uDuYFtFpUMufTvL6Bm9fcSz8Al/tsQQp6GFr/J8f1pdI+Srq80Agydm3L1kzaE TuPQ== X-Gm-Message-State: ALoCoQlzjpXekQsuQ34o+s1TdhjAb/8lpcMkA9sVMtncYoglxjjiwNXCsblXkMNN9FtTGkUbOXIRJuSbzc/LnqKNDolrR3YhdzyVvEg8ll6Q/lyBZEjzG17n7RPChHWkPSiPwZM7qZ5/DJ1A8biRK51WFyKkNu3BGQD9sbP0ohft9NY1Aufbr4VsZZQAQxFcaVIet/T904+o X-Received: by 10.58.37.67 with SMTP id w3mr827265vej.22.1393959412287; Tue, 04 Mar 2014 10:56:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Tue, 4 Mar 2014 10:56:31 -0800 (PST) In-Reply-To: <53161BA7.3070405@drh-consultancy.co.uk> References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161BA7.3070405@drh-consultancy.co.uk> From: Adam Langley Date: Tue, 4 Mar 2014 13:56:31 -0500 Message-ID: To: Dr Stephen Henson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q_pEJkv_pn9JoWRi15fStYH5tD0 Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 18:57:00 -0000 On Tue, Mar 4, 2014 at 1:29 PM, Dr Stephen Henson wrote: > It has been a while since I looked at this in detail but from memory it > effectively meant the explicit part of the IV had to be generated by the module > itself on encrypt. I feel this is a problem that FIPS needs to sort out (they don't have a concept of an AEAD, I assume). I'm unwilling to have the whole world waste bandwidth, and have a more dangerous specification, because of a bureaucratic problem. Cheers AGL From nobody Tue Mar 4 11:44:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E751A02BA for ; Tue, 4 Mar 2014 11:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 yLgtZrk05p6i for ; Tue, 4 Mar 2014 11:44:10 -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 48B581A02A2 for ; Tue, 4 Mar 2014 11:44:10 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id id10so4890977vcb.27 for ; Tue, 04 Mar 2014 11:44:06 -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=RuyHliuLZHL3FUFVAIPvzQPMp1tfwS5f2x85eZGfLP8=; b=XBTtSBsacP4ercLCDT5YHEl/SeAW+Lx2VvVKzeso/3yRCISCeYQ9WF1sR6NCXRqUUB wBiUfwdGttrQKkITciCopD0ji0bqSrXTFWTFxqq2KB8O/NEMskt9OAXiMzPKD/ly6cUB z4O8Y6gA/BiM+4SqEGic6AoOKYyd4omrd+9EyKTb3mRG+57ClBDT9JC+V/3dihJ8QRTJ Z38zU2SVls0rhVbpD5MeYibAuihJqC1C2NmDIabJI3LQaVnCskoGasrwaobUJxSarWf5 CVcXocZ+UtzrDaeDbFXgo5aGYbmuG6sXq2hstymbew2GklJcadgwmY1GD1NJax0qUcSm Sr5A== 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=RuyHliuLZHL3FUFVAIPvzQPMp1tfwS5f2x85eZGfLP8=; b=L87572aZ9/1bFJ0obIxhxbvSFhsmbiDCei1AX0aKrzE02+/Ny7cTyh6rdsypNOtVnP TtzTJSS6AlWo2Q9Htare1GiwSmHn/LGPLI4BSWFh1hTN1TC6UXfrzO+bA1FKMAhvV9oo eBWaAES8iYVoM4ruNwm2bsmQaxnBQ9nNweAnnqbfmSO66Uu3NmEHIQ1VurAkOgXRBvu5 /Anr9Ocey6qnl0/C35hIej17+kZ72ntrNxvgyoARFvxNmCwwT5DeQbWkyBkGWdlb7I/e Mbb8SoCn6H5pnPX87FcG+THWdZI3Tqju2w9opCSJp+909rrFRyWoh++FO8BYYgJI33IV lHeg== X-Gm-Message-State: ALoCoQlVl6no/LPQVcMPAj7z1hw/n5g4oWZXag1sJc65fjjyhQ5a00+aR4VHrUQ+EcGJHJySyCOG0SdE17+DwjI5h/OYMybp6p/X0kzRxypeAcO5Y12A0cgIPx5ah+9s41QG0JSm4Z7GCLKJL6ijHRlvmYhV1UaOAnn9VKILZIFrsGqZ0LVB3PKlWpi9bDlkm4D55VzogsKl MIME-Version: 1.0 X-Received: by 10.220.103.141 with SMTP id k13mr946112vco.25.1393962245848; Tue, 04 Mar 2014 11:44:05 -0800 (PST) Received: by 10.52.109.101 with HTTP; Tue, 4 Mar 2014 11:44:05 -0800 (PST) In-Reply-To: <53161825.7060409@bbn.com> References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.com> Date: Tue, 4 Mar 2014 11:44:05 -0800 Message-ID: From: Wan-Teh Chang To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qJBMroxM42TUM_rPJSEbjEXkp2s Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 19:44:12 -0000 Hi, I researched the FIPS validation of AES-GCM recently. My conclusion was that using an externally-provided nonce/IV for AES-GCM is acceptable for FIPS 140-2 validation. Details: On the NIST AES algorithm validation list (http://csrc.nist.gov/groups/STM/cavp/documents/aes/aesval.html), please search for "GCM". You will see several validated GCM implementations with "IV Generated: ( Externally )". A specific example that you can inspect easily is AES Certificate #2216, for the CNG in Windows 8: http://csrc.nist.gov/groups/STM/cavp/documents/aes/aesval.html#2216 This AES algorithm certificate is part of FIPS 140-2 validation certificate #1892 (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2013.htm#1892). Its security policy states that the BCryptEncrypt function is used for AES-GCM encryption. The BCryptEncrypt function requires the caller to provide the nonce for AES-GCM. See the pbNonce field of the BCRYPT_AUTHENTICATED_CIPHER_MODE_INFO structure described at http://msdn.microsoft.com/en-us/library/windows/desktop/cc562981(v=vs.85).aspx So I concluded that an AES-GCM implementation that only accepts externally-provided nonce/IV can still be FIPS validated. Also, in certain cases, a crypto module can verify that the externally-provided nonces/IVs are not repeated. For example, if the nonces are generated by a counter, the crypto module can easily verify they are monotonically increasing. This approach as an alternative to an internal IV generator is also described in David McGrew's draft: https://tools.ietf.org/html/draft-mcgrew-iv-gen-03#section-5.1 Note: I worked on the FIPS 140-2 validation of a software crypto module at Level 2 (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm#814), so I am not completely ignorant of FIPS validation issues. Wan-Teh Chang From nobody Tue Mar 4 11:56:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544ED1A01C1 for ; Tue, 4 Mar 2014 11:56:21 -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 T-6c1VBf0YRu for ; Tue, 4 Mar 2014 11:56:18 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id DC4CF1A01B0 for ; Tue, 4 Mar 2014 11:56:17 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s24JuAF4029177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Mar 2014 20:56:10 +0100 (MET) In-Reply-To: To: Adam Langley Date: Tue, 4 Mar 2014 20:56:10 +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: <20140304195610.7AF1F1AC3B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bZJe6pbXE-vi2leoQ7dtQ9TAvug Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after Resumption 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, 04 Mar 2014 19:56:21 -0000 Adam Langley wrote: > Dr Stephen Henson wrote: >> >> I'd be interested if anyone knows of examples where the server certificate >> does have to change during renegotiation and how common that practice is. > > Chrome outright rejects renegotiations where the leaf certificate > changes and we've had no reported issues. I'd be glad to enforce such a policy, but I'm less confident that it'll work that smoothly. While it would be intuitively obvious that a server that replaces his server credential/cert should also dispose of his server-side TLS session cache contents along with the old credential/cert, it largely depends on how the stuff is implemented. There seem to be some funny server-side TLS session cache designs out there in the wild. A while ago I noticed that it was possible to resume a TLS session originally established with https://www.google.com/ when proposing that session for resumption to https://docs.google.com/ (not using any TLS extension here, neither SNI or TLS session tickets). However these two servers/services use distinct server certificates, and the server certificate returned by https://www.google.com/ fails rfc2818 section 3.1 server endpoint identification for docs.google.com, which is why my SSL wrapper noticed that behaviour (the client should not have proposed that session resumption in the underyling scenario, so fixing it was straightforward). -Martin From nobody Tue Mar 4 12:17:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D341A028C for ; Tue, 4 Mar 2014 12:17:03 -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 vLmkbdW-5zib for ; Tue, 4 Mar 2014 12:16:59 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 806781A01C1 for ; Tue, 4 Mar 2014 12:16:59 -0800 (PST) Received: from [31.133.167.72] (dhcp-a748.meeting.ietf.org [31.133.167.72]) by che.mayfirst.org (Postfix) with ESMTPSA id A297AF984; Tue, 4 Mar 2014 15:16:53 -0500 (EST) Message-ID: <531634B2.8050004@fifthhorseman.net> Date: Tue, 04 Mar 2014 20:16:50 +0000 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: Adam Langley , Dr Stephen Henson References: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> <5315DD23.30901@drh-consultancy.co.uk> <5315F9BA.4060805@drh-consultancy.co.uk> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x6oD1K0vQfWnbIgp4gHcrHF0897Td5IdD" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1OZSZfYerfnkVDOMzGsJRAKGrwc Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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: Tue, 04 Mar 2014 20:17:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x6oD1K0vQfWnbIgp4gHcrHF0897Td5IdD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/04/2014 04:11 PM, Adam Langley wrote: > On Tue, Mar 4, 2014 at 11:05 AM, Dr Stephen Henson > wrote: >> I'd be interested if anyone knows of examples where the server certifi= cate does >> have to change during renegotiation and how common that practice is. >=20 > Chrome outright rejects renegotiations where the leaf certificate > changes and we've had no reported issues. If a client currently doesn't want to leak SNI to a passive attacker and is willing to burn roundtrips, it can make a non-SNI TLS handshake to the server (accepting whatever certificate is given) and then immediately trigger renegotiation with the SNI header. tstclnt (from mozilla's NSS) has command line options to offer different SNI values at renegotiation. If chrome doesn't do this, it's reasonable for it to reject changed EE certs on renegotiation. But that doesn't rule out this use case. --dkg --x6oD1K0vQfWnbIgp4gHcrHF0897Td5IdD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTFjSyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcT7gP/3waGkpXvR85n4Ge5ssOHACM IiOF91nibneWwb30caPYlnnqJgdxxnYXWJrSV/S7nDcqwQ3S25WzfQe4+sgnIXKU WbFIE/9fUCDM8BMP5JjY7YHoleroWrpNe5CFlML9Sbz72Ai//pV0znQsb4k6tsj4 fUNmNG/Sti+tAn7H+0PSPnGzYyzMxpwrI7ikhim9+PI97WdzSv2OdcHGHackS5Wf 3EELrg+VMw5hDybB3hLhZX/QOvyZTgRD6YOxmqobBUHmge4mMc+tuNAT5NutuWZv FpgoFrUa/bcxP4Pgw4wIV40rLo8tNoBr+QM/QaJsyTzqedtja8ROYmFT8ydRltsV ujx1GWTmMs/tS8uPSbSQ2ytW1GxS7jdTKg7EOdegFz/Jax1EcJfKMwH4JJWeUIWN p3kkYD3mnV+4ztvY3KEsvKswu7vk9TXSq3VCaxCpax2jIXdgJ1ZA0Vp3+ryZ77qH T/iNlgV98nUf9Ke0RqbgF0eD73XYBHfADzf738FdNxYgPgyRLz2TMm0cMXXEJWVo fWJD9tw2O/dWHfSXaB47cM1+xmwcC9Xkg6VioXE294hr0BpIBAcEH4u8LWAtCL03 9azmbN2LWuJdBz8y96LlmFcXyy2AOVZx8+hql9pLVOrJB5wn/fhpx2xBZquGmTzm KBBmdbE0l8p3K3EmYqbC =IlXL -----END PGP SIGNATURE----- --x6oD1K0vQfWnbIgp4gHcrHF0897Td5IdD-- From nobody Tue Mar 4 12:23:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B8E1A02BC for ; Tue, 4 Mar 2014 12:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34glxtwGvVI8 for ; Tue, 4 Mar 2014 12:23:09 -0800 (PST) Received: from claranet-outbound-smtp00.uk.clara.net (claranet-outbound-smtp00.uk.clara.net [195.8.89.33]) by ietfa.amsl.com (Postfix) with ESMTP id AA7521A02E3 for ; Tue, 4 Mar 2014 12:22:50 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:36407 helo=[192.168.7.9]) by relay10.mail.eu.clara.net (relay.clara.net [81.171.239.30]:10465) with esmtpa (authdaemon_plain:drh) id 1WKvrQ-0005rJ-1T for tls@ietf.org (return-path ); Tue, 04 Mar 2014 20:22:44 +0000 Message-ID: <53163611.1040606@drh-consultancy.co.uk> Date: Tue, 04 Mar 2014 20:22:41 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PelUqeSioL_Nn26C89OTlNPpHNc Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 20:23:11 -0000 On 04/03/2014 19:44, Wan-Teh Chang wrote: > > I researched the FIPS validation of AES-GCM recently. My conclusion > was that using an externally-provided nonce/IV for AES-GCM is > acceptable for FIPS 140-2 validation. > I'd be interested to know if that has changed in the last few years. We had to go to quite a bit of trouble specifying how the IV was generated in some detail... an experience I'd have gladly avoided. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nobody Tue Mar 4 12:43:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACC71A0235 for ; Tue, 4 Mar 2014 12:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBgtA-slcuA3 for ; Tue, 4 Mar 2014 12:43:18 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (agjbgdcfdbge.dreamhost.com [69.163.253.164]) by ietfa.amsl.com (Postfix) with ESMTP id C36F31A02F8 for ; Tue, 4 Mar 2014 12:43:18 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 78F2B10070 for ; Tue, 4 Mar 2014 12:43:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=K0vyxA+ocaGXBntxQN8T 0L6G1D4=; b=p15CpVhaOqNhKqfdss5FmiipbA1lrtDauTz6Jg17tKSQIjA3k+Wf pAM6TZiv2Oi53uKoc764TkW0IjLaQo9QyKcUUvoafm6W4J7Y0myZ5V0+dlXA1Z3p iRT/dMc3BE1dguAot+hfx0eIV8dYHJq3rUl727onKTH+YcTJIkZHqjE= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 24C911006E for ; Tue, 4 Mar 2014 12:43:14 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id u57so79187wes.36 for ; Tue, 04 Mar 2014 12:43:14 -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=92gMci2JJ8G4P+cOvMKQb5NKoCo4LdtVVhQN5BpaY+U=; b=fKWmux0YJ5zzB1tkTHnqY4XqRzERwf5uweEqjFlRzj1YYjgBwWCFqwV77PdWZG1VQI F6znD4AGlTMRh0qfUfWZdlt+sqwmpibDsuulWEVAiz9iizv0fecW5WFPBAX+b7giibkM CygRDdBQkRpt8RzxZQRlkv8xhU/yVJde+qVgNeeCUXE0aW5CSUBPJ+0JT0/Ws75Z2Lnz nZtB6KV4tpfeHRGlV49ptQokIAI//eF4JSh8uP+TZAQYtZPSXAPKnMvqfqet/dlhG0jL MpHg6nm6ARiFzger/PKPohg4rpfGOxtblbhkhcIN899xw8faiWA1mKFqcVtUWtZ1R+OW whcw== MIME-Version: 1.0 X-Received: by 10.194.179.69 with SMTP id de5mr2689784wjc.4.1393965794082; Tue, 04 Mar 2014 12:43:14 -0800 (PST) Received: by 10.217.108.132 with HTTP; Tue, 4 Mar 2014 12:43:14 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Mar 2014 14:43:14 -0600 Message-ID: From: Nico Williams To: Karthikeyan Bhargavan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jm1bt2aNknUzORLRvWTz-ZNvlQQ Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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: Tue, 04 Mar 2014 20:43:19 -0000 Scott Cantor points out -rightly- that tls-server-end-point channel bindings also have a problem if resumption+renegotiation can result in the session over which authentication takes place to have the correct server certificate. Nico -- From nobody Tue Mar 4 12:48:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA161A0325 for ; Tue, 4 Mar 2014 12:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNTgF14z_QaV for ; Tue, 4 Mar 2014 12:48:22 -0800 (PST) Received: from claranet-outbound-smtp05.uk.clara.net (claranet-outbound-smtp05.uk.clara.net [195.8.89.38]) by ietfa.amsl.com (Postfix) with ESMTP id 61CBD1A0324 for ; Tue, 4 Mar 2014 12:48:22 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:23717 helo=[192.168.7.9]) by relay15.mail.eu.clara.net (relay.clara.net [81.171.239.35]:10465) with esmtpa (authdaemon_plain:drh) id 1WKwGA-0002NX-GJ for tls@ietf.org (return-path ); Tue, 04 Mar 2014 20:48:18 +0000 Message-ID: <53163C0E.7090809@drh-consultancy.co.uk> Date: Tue, 04 Mar 2014 20:48:14 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.com> <53163611.1040606@drh-consultancy.co.uk> In-Reply-To: <53163611.1040606@drh-consultancy.co.uk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JE-D24VyF1ABSDZ0B-ByLhXzbnc Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 20:48:24 -0000 On 04/03/2014 20:22, Dr Stephen Henson wrote: > On 04/03/2014 19:44, Wan-Teh Chang wrote: >> >> I researched the FIPS validation of AES-GCM recently. My conclusion >> was that using an externally-provided nonce/IV for AES-GCM is >> acceptable for FIPS 140-2 validation. >> > > I'd be interested to know if that has changed in the last few years. We had to > go to quite a bit of trouble specifying how the IV was generated in some > detail... an experience I'd have gladly avoided. > Weird... I went back through my old notes and found a reference to FIPS140-2 Implementation Guidance (IG): http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf In section A.5 are some comments about AES-GCM including this: 1. The external generation of the IVs is not allowed. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nobody Tue Mar 4 15:11:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF80E1A006A for ; Tue, 4 Mar 2014 15:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxGNWg6rqBdZ for ; Tue, 4 Mar 2014 15:11:40 -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 206931A0076 for ; Tue, 4 Mar 2014 15:11:39 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 477CC28563; Tue, 4 Mar 2014 23:11:36 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 3404228509; Tue, 4 Mar 2014 23:11:36 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 29BE4FE2B4; Tue, 4 Mar 2014 23:11:36 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Tue, 4 Mar 2014 18:11:35 -0500 From: "Salz, Rich" To: Adam Langley , Dr Stephen Henson Date: Tue, 4 Mar 2014 18:11:34 -0500 Thread-Topic: [TLS] ChaCha and IVs Thread-Index: Ac8324e8+dt+fX0+Riy9ZrEIJde2bAAIxE4A Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711EFC395B0@USMBX1.msg.corp.akamai.com> References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161BA7.3070405@drh-consultancy.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MCNLs6tglQdVIH011abgcLwq2Uw Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 23:11:42 -0000 > I'm unwilling to have the whole world waste bandwidth, and have a more da= ngerous specification, because of a bureaucratic problem. For eight bytes. Shrug, okay, your battle (if, in fact, it is; Wan-Teh cou= ld be rightr). Nothing prevents TLS from saying the nonce should be the record number. Ca= reful implementations could compare them. Your company may not care about FIPS, but many TLS users/providers do. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Tue Mar 4 15:17:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABE51A00A8 for ; Tue, 4 Mar 2014 15:17:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAyNDAloqvR9 for ; Tue, 4 Mar 2014 15:17:26 -0800 (PST) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3E64A1A0090 for ; Tue, 4 Mar 2014 15:17:26 -0800 (PST) Received: by mail-qg0-f41.google.com with SMTP id i50so690708qgf.0 for ; Tue, 04 Mar 2014 15:17: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=Cf7YPE818+YLeJMDcHTVQrVSpcl5kvbPlXPMWwwgINw=; b=QFoSKQT9Z1YtOxEGXQngpz1DFSXBVsS2qgAu2eVvNPEAw6JjJm/H7dwsh8Usa3/96f j6Zay9BfLeUWNjSc5hdh3I8ZsFx7ATjbtGafdYsKePlIeiZrJ2zGBgR8CC8FuHQ4uJo1 ZemREMWy/oMlbeu2cxFkzDb/TYcV+L1i4A8PZhrYmXACe99lfimvfDswq0awzWKF3vXG cO1r4/d71klu/qz1tas/cxadPudgoeScEz3nydiv8ojZN6kSW52GpadpZqQKqewdglAC uYjCAE3dRDer3K5Qb4kzVqkYPQatL+kqrakvP3SzbCeNqCvBycv/fbeF3Acrn/Tk42y6 hYlw== X-Gm-Message-State: ALoCoQkRofmq5/ZnLl46ntQKEEOyxotEoCgATQQwQbl40dM9Zu70mw3rvso+gGSz8iPl531oV9We MIME-Version: 1.0 X-Received: by 10.224.60.193 with SMTP id q1mr2788868qah.67.1393975042582; Tue, 04 Mar 2014 15:17:22 -0800 (PST) Received: by 10.224.37.135 with HTTP; Tue, 4 Mar 2014 15:17:22 -0800 (PST) In-Reply-To: <53161825.7060409@bbn.com> References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.com> Date: Tue, 4 Mar 2014 15:17:22 -0800 Message-ID: From: Brian Smith To: Stephen Kent Content-Type: multipart/alternative; boundary=001a1133dee63dcfcf04f3d01be7 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9Q_1RvHz9snzZwL4kJ1jun-MBNE Cc: "" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 23:17:27 -0000 --001a1133dee63dcfcf04f3d01be7 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 4, 2014 at 10:15 AM, Stephen Kent wrote: > Security evaluation for a crypto alg does not include a protocol like ESP > or > (D)TLS; if focuses only on the alg implementation. Thus a TLS "guarantee" > of uniqueness is not relevant. Anyone who has had a product evaluated will > tell you that the goal is always to minimize the amount of code that is > subject > to review. If one were to use a TLS (or ESP) sequence number for an IV, > all of > the protocol code would be part of the evaluation, and that would make the > evaluation prolonged and very costly. ChaCha20-Poly1304 can't be validated anyway, even if it used explicit IVs, because it isn't an algorithm that has been approved by any agency that requires validation. One can have the crypto component generate the ciphertext and the counter IV in a way that is guaranteed to be a monotonically increasing sequence. This code would be the code that would be validated. Then, have your TLS implementation take that counter IV that was output from the crypto component and verify that it matches the current record number, and fail if there is a mismatch. Certification programs exist, in theory, to ensure that we do good, safe things. In this case, we have a bit of bureaucracy that is getting in the way of doing something that is clearly good and safe. The best solution to that problem is to fix the bureaucracy. If one cannot fix the bureaucracy then one can simply avoid implementing ChaCha20-Poly1304 and implement AES-GCM or other cipher suites instead. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) --001a1133dee63dcfcf04f3d01be7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Mar 4, 2014 at 10:15 AM, Stephen Kent <kent@bbn.com> wrote:
Security evaluation for a crypto alg does not include a protocol like ESP o= r
(D)TLS; if focuses only on the alg implementation. Thus a TLS "guarant= ee"
of uniqueness is not relevant. Anyone who has had a product evaluated will<= br> tell you that the goal is always to minimize the amount of code that is sub= ject
to review. If one were to use a TLS (or ESP) sequence number for an IV, all= of
the protocol code would be part of the evaluation, and that would make the<= br> evaluation prolonged and very costly.

ChaCh= a20-Poly1304 can't be validated anyway, even if it used explicit IVs, b= ecause it isn't an algorithm that has been approved by any agency that = requires validation.

One can have the crypto component generate the ciphertext an= d the counter IV in a way that is guaranteed to be a monotonically increasi= ng sequence. This code would be the code that would be validated. Then, hav= e your TLS implementation take that counter IV that was output from the cry= pto component and verify that it matches the current record number, and fai= l if there is a mismatch.

Certification programs exist, in theory, to ensure that we d= o good, safe things. In this case, we have a bit of bureaucracy that is get= ting in the way of doing something that is clearly good and safe. The best = solution to that problem is to fix the bureaucracy. If one cannot fix the b= ureaucracy then one can simply avoid implementing ChaCha20-Poly1304 and imp= lement AES-GCM or other cipher suites instead.

Cheers,
Brian
--
Mozilla Networking/Cry= pto/Security (Necko/NSS/PSM)

--001a1133dee63dcfcf04f3d01be7-- From nobody Tue Mar 4 15:19:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC291A00AB for ; Tue, 4 Mar 2014 15:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 58FFuY7dDjI6 for ; Tue, 4 Mar 2014 15:19:20 -0800 (PST) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 397BA1A0090 for ; Tue, 4 Mar 2014 15:19:20 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id sa20so243117veb.22 for ; Tue, 04 Mar 2014 15:19:16 -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=Jo9MdsZHEPNcRm939onHISaNUQPQzs28doN9MWA1SO8=; b=Jqo6MAzDgvIh8XibXyNlecbzqS5+kxaXvkpfWKPxBWRLUCn7yDaz1MvGkcD+KeThCA wmwcwCaXuLTA2q9078aFhQygP0vxifHqDzByR+/uq6Wr3o+9YXf0U9dLHefJDrVy2XdE uutpO4uiTbs4ZbJL98yk2baqGym7cwb/it7LCgvI8bMeDdl+LlvKLFGj5+OE081P4D/3 YqoHnFxt+0eRdMTghG9nP6dDCnyra4Rf7LtyWMZ0GI0K+vm9lJ5WpFgRLAODXrbIF5DW RhI2a/q11doOE18x8LkG95XtpZm6Gzo4Q3lOdUJbH79an3GSAHMcm/W9yCMxzTsS8FBC bcgg== 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=Jo9MdsZHEPNcRm939onHISaNUQPQzs28doN9MWA1SO8=; b=BEOY03HuU7Meb4e4happXOy5jozGtbYHmK+kPi8EMTxM8dLcbEEY8J0sjfoIaZM9JB vxQoxDTwxrzYGxuMGUI72sXoumwfH7ZSyyN3MipCCM5r68KnXqciyFrEN3CZNSi243+K cPIEkBjbVWg3MXnJtatxsrC1/HGR18PP9Drp72PUGed6wEQpnOK1pWCkustk6uh2JlYC vRbbqZChNP8yewozL9a6X9RmCdSRY/+9gu11Z4XWzBvam1aBcnKM6qqxNruulnyVT0bk LV2Mtv15wGHjE/C6708xhVpa8jXJQwOqpM1iMcK63N9+tU1x6nZJ/euaaUeyflMGeGec BqYA== X-Gm-Message-State: ALoCoQms0hJM9pWPu9BUj/BVnZcMEAN5E2KtWYOHgBJ1MM+t27yFSRENiYo77kL5QoJItaOJQipXszDD+ZggTdASRbAD0uLrNz2EbPQuom2oqzKE5/FmfCykZI3sTEhRD87fj8yQxf43dAzzr+267cBh5jgffhxDoy/3sAILfplix8dZHDOXZQwnwUot51srsVc3+vNqKEcV X-Received: by 10.58.69.111 with SMTP id d15mr1763737veu.3.1393975156530; Tue, 04 Mar 2014 15:19:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Tue, 4 Mar 2014 15:18:56 -0800 (PST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711EFC395B0@USMBX1.msg.corp.akamai.com> References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161BA7.3070405@drh-consultancy.co.uk> <2A0EFB9C05D0164E98F19BB0AF3708C711EFC395B0@USMBX1.msg.corp.akamai.com> From: Adam Langley Date: Tue, 4 Mar 2014 18:18:56 -0500 Message-ID: To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_pwiRagzCe0pKMQ8TloGYQDkbRI Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 23:19:21 -0000 On Tue, Mar 4, 2014 at 6:11 PM, Salz, Rich wrote: > For eight bytes. Shrug, okay, your battle (if, in fact, it is; Wan-Teh could be rightr). 8 bytes is ~0.6% of bandwidth assuming that one is sizing records to packets. It's not huge, but it's not trivial. > Your company may not care about FIPS, but many TLS users/providers do. I understand, but I'm quite happy to apply pressure to FIPS to be reasonable here. Cheers AGL From nobody Tue Mar 4 15:35:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F521A0059 for ; Tue, 4 Mar 2014 15:35:12 -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 qBUJ02QmUjZh for ; Tue, 4 Mar 2014 15:35:09 -0800 (PST) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id AD0AE1A0079 for ; Tue, 4 Mar 2014 15:35:07 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id x13so312233qcv.5 for ; Tue, 04 Mar 2014 15:35:04 -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=WaBOMHf+N0DGj0zy4nT4alfn/W9tgo7CdLTK6qWDAOg=; b=ZBEpOj+Btb1HcsosLFVCJcXnOvngAhZsQrAXEMcxS4Y7YXxctQIKMx7N315HC+p9zb EKmf70tCZdgFqY1Ou/NyxkydP919ZXeiFpUlHAQiFID7PfqvB1kYOjN9zoHzJ01mFo9n Qx85NNJjpO8m3Eqjj0C+Iaw71HEh2Yabpa5D0osNb2N1PL8HV4ZpNxCATCabRrNVZipL YEg9uyX/9VFp8gZ73KeW0cdrJz92C/6CyOe7vFb+KQkaZzp8ZrkXQsqnfztpZ22fKlfI fgr7tewJEyQVYgq/m1XWKumTgXmwrdgpTX26R8LK2fNzp5KCVF4RJLFJ5vnaT1QunF3o I5Jw== X-Gm-Message-State: ALoCoQkc7pwo9sw/2F1K/O2sd0L7RrRd3Ht5V9suxpeDyTLt25n/td47VwjyF2TI0XmLuFtQmlJn MIME-Version: 1.0 X-Received: by 10.224.30.69 with SMTP id t5mr3180316qac.30.1393976104222; Tue, 04 Mar 2014 15:35:04 -0800 (PST) Received: by 10.224.37.135 with HTTP; Tue, 4 Mar 2014 15:35:04 -0800 (PST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711EFC395B0@USMBX1.msg.corp.akamai.com> References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161BA7.3070405@drh-consultancy.co.uk> <2A0EFB9C05D0164E98F19BB0AF3708C711EFC395B0@USMBX1.msg.corp.akamai.com> Date: Tue, 4 Mar 2014 15:35:04 -0800 Message-ID: From: Brian Smith To: "Salz, Rich" Content-Type: multipart/alternative; boundary=047d7bf0e80084cb1f04f3d05a32 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dFQl_4pup5Z_S79PMjDzLgKHKqk Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Mar 2014 23:35:12 -0000 --047d7bf0e80084cb1f04f3d05a32 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 4, 2014 at 3:11 PM, Salz, Rich wrote: > Your company may not care about FIPS, but many TLS users/providers do. > There is a difference between not caring about FIPS and believing that the solution to this conflict is to fix the validation requirements. If we were to require everything that IETF does to conform to NIST requirements then NIST would effectively have veto power over everything that the IETF does. That should never be the case. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) --047d7bf0e80084cb1f04f3d05a32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Mar 4, 2014 at 3:11 PM, Salz, Rich <rsalz@akamai.com> wro= te:
Your company may not care about FIPS, but many TLS users/providers do.
<= /blockquote>
There is a difference betw= een not caring about FIPS and believing that the solution to this conflict = is to fix the validation requirements. If we were to require everything tha= t IETF does to conform to NIST requirements then NIST would effectively hav= e veto power over everything that the IETF does. That should never be the c= ase.

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
--047d7bf0e80084cb1f04f3d05a32-- From nobody Tue Mar 4 16:35:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A491A00D3 for ; Tue, 4 Mar 2014 16:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOHpT4UsHiyG for ; Tue, 4 Mar 2014 16:35:28 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id F3FC21A00D1 for ; Tue, 4 Mar 2014 16:35:27 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5623947385; Wed, 5 Mar 2014 00:35:24 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 418DC47384; Wed, 5 Mar 2014 00:35:24 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 3623F22C8; Wed, 5 Mar 2014 00:35:24 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Tue, 4 Mar 2014 19:35:23 -0500 From: "Salz, Rich" To: Brian Smith Date: Tue, 4 Mar 2014 19:35:19 -0500 Thread-Topic: [TLS] ChaCha and IVs Thread-Index: Ac84AmBEAadpyCwySa+b6v4I9GbO1gAB1tDA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711EFC395CB@USMBX1.msg.corp.akamai.com> References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161BA7.3070405@drh-consultancy.co.uk> <2A0EFB9C05D0164E98F19BB0AF3708C711EFC395B0@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: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C711EFC395CBUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DyZd3S9QmboRdSm-XKONdEGtDUE Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Mar 2014 00:35:31 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C711EFC395CBUSMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PlRoZXJlIGlzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIG5vdCBjYXJpbmcgYWJvdXQgRklQUyBhbmQg YmVsaWV2aW5nIHRoYXQgdGhlIHNvbHV0aW9uIHRvIHRoaXMgY29uZmxpY3QgaXMgdG8gZml4IHRo ZSB2YWxpZGF0aW9uIHJlcXVpcmVtZW50cy4NCkVuZ2luZWVyaW5nLCBlc3BlY2lhbGx5IHNlY3Vy aXR5LCBpcyBhIHRyYWRlLW9mZi4gU29tZXRpbWUgdGhlIHRyYWRlLW9mZnMgYXJlIHdoaWNoIGJh dHRsZXMgdG8gZmlnaHQuDQo+IElmIHdlIHdlcmUgdG8gcmVxdWlyZSBldmVyeXRoaW5nIHRoYXQg SUVURiBkb2VzIHRvIGNvbmZvcm0gdG8gTklTVCByZXF1aXJlbWVudHMgdGhlbiBOSVNUIHdvdWxk IGVmZmVjdGl2ZWx5IGhhdmUgdmV0byBwb3dlciBvdmVyIGV2ZXJ5dGhpbmcgdGhhdCB0aGUgSUVU RiBkb2VzLiBUaGF0IHNob3VsZCBuZXZlciBiZSB0aGUgY2FzZS4NCkRpZCBJIGdpdmUgeW91IHRo ZSBpbXByZXNzaW9uIHRoYXQgSSBzYWlkIGFueXRoaW5nIGNsb3NlIHRvIHRoaXM/DQoNClNvbm55 LCBJIHBvc3RlZCBERVMgdG8gVXNlbmV0IGJhY2sgaW4gdGhlIERhcmsgQWdlcyBhbmQgdGhlbiBh cnJhbmdlZCB0byBnZXQgaXQgcmUtcG9zdGVkIGZyb20gQXVzdHJhbGlhIChzZWFyY2ggZm9yIOKA nGRlcy1uby11c2HigJ0sIHF1b3RlcyBwcm9iYWJseSByZXF1aXJlZCkuICBIYXZlIHNvbWUgcmVz cGVjdCDimLoNCg0KICAgICAgICAgICAgICAgIC9yJA0KLS0NClByaW5jaXBhbCBTZWN1cml0eSBF bmdpbmVlcg0KQWthbWFpIFRlY2hub2xvZ3kNCkNhbWJyaWRnZSwgTUENCg0K --_000_2A0EFB9C05D0164E98F19BB0AF3708C711EFC395CBUSMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48 ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1i b3R0b206MTIuMHB0Jz4mZ3Q7VGhlcmUgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4gbm90IGNhcmlu ZyBhYm91dCBGSVBTIGFuZCBiZWxpZXZpbmcgdGhhdCB0aGUgc29sdXRpb24gdG8gdGhpcyBjb25m bGljdCBpcyB0byBmaXggdGhlIHZhbGlkYXRpb24gcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPkVuZ2luZWVy aW5nLCBlc3BlY2lhbGx5IHNlY3VyaXR5LCBpcyBhIHRyYWRlLW9mZi4gU29tZXRpbWUgdGhlIHRy YWRlLW9mZnMgYXJlIHdoaWNoIGJhdHRsZXMgdG8gZmlnaHQuIDxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPiZndDsgSWYgd2Ugd2Vy ZSB0byByZXF1aXJlIGV2ZXJ5dGhpbmcgdGhhdCBJRVRGIGRvZXMgdG8gY29uZm9ybSB0byBOSVNU IHJlcXVpcmVtZW50cyB0aGVuIE5JU1Qgd291bGQgZWZmZWN0aXZlbHkgaGF2ZSB2ZXRvIHBvd2Vy IG92ZXIgZXZlcnl0aGluZyB0aGF0IHRoZSBJRVRGIGRvZXMuIFRoYXQgc2hvdWxkIG5ldmVyIGJl IHRoZSBjYXNlLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPkRpZCBJIGdpdmUgeW91IHRoZSBpbXByZXNzaW9uIHRoYXQgSSBzYWlkIGFueXRo aW5nIGNsb3NlIHRvIHRoaXM/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Tb25ueSwgSSBwb3N0ZWQgREVT IHRvIFVzZW5ldCBiYWNrIGluIHRoZSBEYXJrIEFnZXMgYW5kIHRoZW4gYXJyYW5nZWQgdG8gZ2V0 IGl0IHJlLXBvc3RlZCBmcm9tIEF1c3RyYWxpYSAoc2VhcmNoIGZvciDigJxkZXMtbm8tdXNh4oCd LCBxdW90ZXMgcHJvYmFibHkgcmVxdWlyZWQpLsKgIEhhdmUgc29tZSByZXNwZWN0IDwvc3Bhbj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6 IzFGNDk3RCc+Sjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIC9yJDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4gPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0twqAg PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPlByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ba2FtYWkgVGVjaG5vbG9n eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5DYW1icmlkZ2UsIE1BPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_2A0EFB9C05D0164E98F19BB0AF3708C711EFC395CBUSMBX1msgcorp_-- From SRS0=QKSf=YG=acm.org=bmoeller@srs.kundenserver.de Tue Mar 4 18:25:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2121F1A0148 for ; Tue, 4 Mar 2014 18:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 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.547, 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 b3t6jmpFDu5e for ; Tue, 4 Mar 2014 18:25:15 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.131]) by ietfa.amsl.com (Postfix) with ESMTP id 343571A013C for ; Tue, 4 Mar 2014 18:25:05 -0800 (PST) Received: from mail-yh0-f50.google.com (mail-yh0-f50.google.com [209.85.213.50]) by mrelayeu.kundenserver.de (node=mreue001) with ESMTP (Nemesis) id 0MQBed-1WGMgA2hxj-005Ezg; Wed, 05 Mar 2014 03:25:02 +0100 Received: by mail-yh0-f50.google.com with SMTP id t59so416138yho.37 for ; Tue, 04 Mar 2014 18:25:00 -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=UUvzi3e8EokXtcN7KFDwrhgVfglDNdhkSWC1Pu4r2WM=; b=PqmIEKqW/bQ8jCPvh+SgeRWAjpkGJ8hbJQVRwtSsrzi8geeiV4gXA2MZSR+LZAw+ro xxf14k3bre/K+sMUBCVOKBxG2Nw730wtZSjUhW3gr09FM9cRhIVeecsQq+uwLHOsh384 uclT2LvEVNVMbzpkmbXKPTdfFlVFKPykyId1mej3yBCeiYKE0vBEt9o/RmF3NYPvlXy1 u+ovFCjlnXjC90/4SgxIO+/Tk6/JKIWbU1XTq09A/vG5Z2lkBdm71B4PHJfOG2KFEJZ5 i7pC3w+XLoOyG7H2pJM8JaN0SgPQgjjzwNYK6q7keIII0B8brvzRIpl+vZ8DJXRdu/w9 GFqw== MIME-Version: 1.0 X-Received: by 10.236.229.195 with SMTP id h63mr105904yhq.121.1393986300616; Tue, 04 Mar 2014 18:25:00 -0800 (PST) Received: by 10.170.78.5 with HTTP; Tue, 4 Mar 2014 18:25:00 -0800 (PST) In-Reply-To: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> References: <5314AF9B.8000402@drh-consultancy.co.uk> <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> Date: Tue, 4 Mar 2014 18:25:00 -0800 Message-ID: From: Bodo Moeller To: Martin Rex Content-Type: multipart/alternative; boundary=001a11c1e2084529bd04f3d2ba0c X-Provags-ID: V02:K0:TiJzXmDrqHjwX7rlIuETTTGiic1WPxnGWEP2NbPlOJr ksJ8fmKgeqjPsQeo0ug9iaTFttUDWxUT9s3iT3a0cvvGc/noul Mf3ndmlhPYOe3pEin383nhAHvgKSQMs7ZGIVaraWOc+1guTYPX mC23fKLVagK+LKgTaz7AyT4g3JguvRRC9LJAmPKdLzEiR3Zbz4 tNFWAlAGtJH36qkUP+w6heMVqxw2Q80+WfYvvrsDAkZ8GIvgeY WM0mL5x874fSrsW3MsDdZ9cCClQnxYckfIPdSUxcTOvS2ALIQI z6Uxms8LT9TqiM2GTfwWw64KxjCQGAkQKQ+NMUQ8hKp97X9ODt VNgkCr6Y/xVgzY7ziyqhnzoqQ8W14Vo4dw0gnyJUDIJIyi9kx5 h4kAvjrIe/QLll9/0RZlNaiWSi/MlFDFA6hTd7TNsozIb/qQeI ElrmP Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hZWFDbGVZUxUmOVPgTePoCQBaes Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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: Wed, 05 Mar 2014 02:39:46 -0000 --001a11c1e2084529bd04f3d2ba0c Content-Type: text/plain; charset=ISO-8859-1 Martin Rex : > Dr Stephen Henson wrote: > > > If the client checks the hostname against the certificate whenever a > > certificate is presented[2] then additionally the attacker needs a > certificate > > with the same hostname as the attacked server. > > > > 2. This isn't always the case. Some applications check the hostname only > after > > the handshake has completed. > > An application client that is using a TLS library _without_ callbacks, > and requests a blocking TLS handshake to be performed, will only get to > see the server certificate after the handshake has completed. > > While the X.509 cert chain validation might be performed in-band > by the TLS stack, the rfc2818 Section 3.1 server endpoint > identification is left up to the application caller. I certainly agree that there's an issue here, but I don't see how (in the context of the Triple Handshake Attack) this is about whether a handshake has completed. Maybe what you (Steve and Martin) mean is that some applications only check once, after the *initial* handshake on the connection has completed (not checking again if another, renegotiation, handshake completes)? Bodo --001a11c1e2084529bd04f3d2ba0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Martin Rex=A0<= /span><mrex@sap.com&g= t;:
Dr Stephen Henson wrote:
=A0
> If the client checks the hostname against the certificate whenever a> certificate is presented[2] then additionally the attacker needs a c= ertificate
> with the same hostname as the attacked server.
>
> 2. This isn't always the case. Some applications check = the hostname only after
> the handshake has completed.
=A0
An application client that is using a TLS library _without_ call= backs,
and requests a blocking TLS handshake to be performed, will only = get to
see the server certificate after the handshake has completed.

While the X.509 cert chain validation might be performed in-band
by = the TLS stack, the rfc2818 Section 3.1 server endpoint
identification is= left up to the application caller.

I certainly agree that there's an issue here, but I don't see how (= in the context of the Triple Handshake Attack) this is about whether a hand= shake has completed. =A0Maybe what you (Steve and Martin) mean is that some= applications only check once, after the *initial* handshake on the connect= ion has completed (not checking again if another, renegotiation, handshake = completes)?

Bodo

--001a11c1e2084529bd04f3d2ba0c-- From nobody Tue Mar 4 20:09:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E893A1A020C for ; Tue, 4 Mar 2014 20:09:27 -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 tU8h7FdgQTqc for ; Tue, 4 Mar 2014 20:09:25 -0800 (PST) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id 896EF1A0200 for ; Tue, 4 Mar 2014 20:09:25 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id g10so497606pdj.13 for ; Tue, 04 Mar 2014 20:09: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:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9bXeMebKgEyXGXLdF1VkTh7FcFdxIj8Hz9INcgvqjh0=; b=f1J3VDZ7RkNWyRdYTtwNfkr7K/8erPvf/tKoyqvHhQe7OXvrMlUasJIKcxuOa0XRv2 wZCCRh2WXTqMC3lhxIKy3vzQNrYf3+/cBQsxfiwRX/T/rNZQd6uec3FUSdeuDJmewwWC rV/HuAGz1uacQ76k/4V3TUU7WEkQkbGov0H2a+bVd7Wmi0EUOjYQYbnFddMhPSJN48CF FhNmJvGUaKhmPbIdHXzcsaUCmeJcnpj59TaFx9GiC3zlHvsl38XVY7MtkH4NeXaKM2Ge qhtXi+5c7WDR88QtL5tcwQsvRC3kfQ0NIx7J1/zaYw2tx02D5tl8QsdP2sBNca+pKqNm r6zg== X-Gm-Message-State: ALoCoQkgfr0HqBcTl7oqZRKuAJlVxRuPd7JzBCFlCGfKOXCX69TmrgQ1Y6NhqaUgom3EUejOsx2Q X-Received: by 10.67.1.202 with SMTP id bi10mr4185396pad.68.1393992562196; Tue, 04 Mar 2014 20:09:22 -0800 (PST) Received: from [192.168.1.105] ([114.245.173.86]) by mx.google.com with ESMTPSA id ei4sm2777250pbb.42.2014.03.04.20.09.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 20:09:21 -0800 (PST) Message-ID: <5316A363.3000801@Vimino.COM> Date: Wed, 05 Mar 2014 12:09:07 +0800 From: Xuelei Fan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> <5315DD23.30901@drh-consultancy.co.uk> <5315F9BA.4060805@drh-consultancy.co.uk> In-Reply-To: <5315F9BA.4060805@drh-consultancy.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jf4b6wVNv-74Rf0oE_psY_sCDUo Subject: Re: [TLS] MITM Attacks on Client Authentication after 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: Wed, 05 Mar 2014 04:09:28 -0000 On 3/5/2014 12:05 AM, Dr Stephen Henson wrote: > On 04/03/2014 15:23, Martin Thomson wrote: >> On 4 March 2014 14:03, Dr Stephen Henson wrote: >>> >>> I performed a few checks with an experimental option to change the server >>> certificate during renegotiation, which I believe simulates the attack >>> mechanism. If the client checks certificates in band then all versions choke >>> with a verification error if a chain is untrusted. For 1.0.2 only it also chokes >>> if the chain is trusted but the hostname doesn't match. >> >> This is an interesting option. I like the general idea, but wonder >> what "hostname doesn't match" means in this case. >> JSSE enabled the hostname checking during handshaking for HTTPS and LDAP. If hostname doesn't match, the handshaking is terminated immediately. > I'd be interested if anyone knows of examples where the server certificate does > have to change during renegotiation and how common that practice is. > I was wondering, if the cipher suite is changed from RSA cert based to EC cert based (and vice versa), the server certificate would have to change accordingly. Not sure about the case in practice. Xuelei From nobody Tue Mar 4 23:14:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EAB1A0304 for ; Tue, 4 Mar 2014 23:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 8IhtfOGX4kdM for ; Tue, 4 Mar 2014 23:14:00 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 82FD41A02C2 for ; Tue, 4 Mar 2014 23:14:00 -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 s257Du4E015796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 5 Mar 2014 02:13:56 -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 s257Dr79009831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 5 Mar 2014 02:13:55 -0500 Message-ID: <1394003633.20861.22.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "tls@ietf.org" Date: Wed, 05 Mar 2014 08:13:53 +0100 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711EFC393FA@USMBX1.msg.corp.akamai.com> References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C711EFC393FA@USMBX1.msg.corp.akamai.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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0oIfHdw3Lmb6vaHzjGIr2f2C8_s Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Mar 2014 07:14:02 -0000 On Tue, 2014-03-04 at 13:18 -0500, Salz, Rich wrote: > > In TLS the record sequence numbers are unique by definition, thus any > analysis is simplified. > > Ever done a FIPS or similar certification? You have to give them your > source code. You really don't want to require the TLS stack to be > included in that bundle when all you want is certified crypto. I didn't say that FIPS (or any other) certification will be simplified. I said analysis meaning security analysis. regards, Nikos From nobody Tue Mar 4 23:19:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F041A0304 for ; Tue, 4 Mar 2014 23:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 sp5T1qcqmGPx for ; Tue, 4 Mar 2014 23:19:32 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 13C601A033C for ; Tue, 4 Mar 2014 23:19:30 -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 s257JMr5001543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Mar 2014 02:19:23 -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 s257JKVv012311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 5 Mar 2014 02:19:22 -0500 Message-ID: <1394003960.20861.27.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Stephen Kent Date: Wed, 05 Mar 2014 08:19:20 +0100 In-Reply-To: <53161825.7060409@bbn.com> References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vE0-pbuKTaDMc7s0w8N0KZmFSFo Cc: tls@ietf.org Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Mar 2014 07:19:34 -0000 On Tue, 2014-03-04 at 13:15 -0500, Stephen Kent wrote: > >> From a security assurance perspective, an IV based on a > >> protocol-supplied value expands the scope of what has to > >> be analyzed (to ensure uniqueness) > > In TLS the record sequence numbers are unique by definition, thus any > > analysis is simplified. > Security evaluation for a crypto alg does not include a protocol like ESP or > (D)TLS; if focuses only on the alg implementation. Thus a TLS "guarantee" > of uniqueness is not relevant. Anyone who has had a product evaluated will > tell you that the goal is always to minimize the amount of code that is > subject > to review. If one were to use a TLS (or ESP) sequence number for an IV, > all of > the protocol code would be part of the evaluation, and that would make the > evaluation prolonged and very costly. I believe this was answered elsewhere in this thread. > > * It reduces the exchanged data (by 12 or 8 bytes - depending on the > > explicit nonce size). This is particularly important in DTLS where the > > typical record size is less than 1400 bytes. > The typical packet size in the ESP context is at least that small. > > * It ensures that the nonce is unique even until 2^64-1 records are > > exchanged (which is the termination limit for TLS sessions). > this guarantee is only as good as the assurance of the TLS code than manages > the sequence numbers, which is not likely to be secure as the alg > implementation. One cannot design protocols with the assumption that they will be violated. However, even if you are implying that implementations will continue to exchange data even after 2^64-1 records are exchanged, then the counter nonce approach will fail precisely at the 2^64 exchanged record. The random nonce approach will fail much earlier. regards, Nikos From nobody Wed Mar 5 03:11:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA9C1A03EF for ; Wed, 5 Mar 2014 03:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 XqxFDa7mSl-Q for ; Wed, 5 Mar 2014 03:11:43 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBDF1A0489 for ; Wed, 5 Mar 2014 03:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5728; q=dns/txt; s=iport; t=1394017891; x=1395227491; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=b/EXz/9t1hzIilG1lAvDDING11j7FsulbcrsBqcI7G4=; b=CmIwN4NtnBnlHtGvbpU5ba5tJKCko6GyWoyLhI9gTaWxg7ly3CuwdZKu 3YZ2g0/ncmNNW9z0vSdGGzVDYn0UzZyRwAXfb28GbyrFDy/x0GaBKLqjl pSRfH9aQPFzTQbnOctdXHXy0dvfiUjToyC1O1TH2dTRjrqD+Qvf1U8knc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIIAP0FF1OrRDoJ/2dsb2JhbABagwY7wWJCVxZ0giUBAQEDAQEBATU2BQUBBQsLGAkWDwkDAgECARUwBg0BBQICEIddBw7NWhMEjlEHhDgBA4lLiweDa4ZKi2GDSx4 X-IronPort-AV: E=Sophos;i="4.97,592,1389744000"; d="scan'208";a="105091291" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 05 Mar 2014 11:11:30 +0000 Received: from [10.0.2.15] (sjc-vpn6-1579.cisco.com [10.21.126.43]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s25BBRAJ014324; Wed, 5 Mar 2014 11:11:28 GMT Message-ID: <5317065E.1090007@cisco.com> Date: Wed, 05 Mar 2014 06:11:26 -0500 From: David McGrew User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9 MIME-Version: 1.0 To: Watson Ladd References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com> <7A2637AF-5A16-404B-B7A1-49FB17D5345A@callas.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WHf97cTt6B9bQ41V1Lj8gPXCpV0 Cc: Paul Lambert , "cfrg@irtf.org" , Jon Callas , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Wed, 05 Mar 2014 11:11:50 -0000 On 03/04/2014 12:02 PM, Watson Ladd wrote: > Dear all, > This is provisionally my last word on the matter. > > Any consensus based process only works if people will block a largely > formed consensus for a good reason only. A document being unclear, or > having unanalyzed security properties, or major issues with regards to > alternatives not being discussed are good reasons. But the argument > that Paul I think is making, that until the CFRG produces a draft ala > RFC 6090 for Edwards curve we cannot use them, is fundamentally > unconvincing. > > First off, let me note that black box implementations of Curve25519 > using the paper are possible: I've written them, Adam Langley has > written them, as have lots of other people. So that leaves the > argument that the implementations require too much knowledge about > cryptography, and that such an issue is worth blocking specs. > > The simplest argument for why it is unconvincing is the date of RFC > 6090 vs. the dates of protocols that included Suite B and ECC. RFC > 4869 includes Suite B a full 4 years before RFC 6090 was published. > Now, it is possible that Paul's argument was valid, but simply wasn't > raised at the time RFC 4869 was being published. But I don't see any > evidence that implementors of RFC 4869 were hamstrung by the > nonexistence of RFC 6090. > > The second reason I am unconvinced is that I don't see why we > shouldn't assume the availability of standard references such as the > Handbook Of Elliptic and Hyperelliptic Curve Cryptography, or volume 2 > of Knuth, to implementors. Such documents are available for far less > money than ISO standards, and in many regions of North America, Europe > and Asia, can be found for free in the library. The goal of a spec is > to explain to humans what is to be done: including excessive > information makes this much harder. > > Finally, Mr. Lambert writes in terms of the "onus" being on CFRG to > produce such a document, which he calls a "usable normative > reference". Such a bare assertion is entirely unconvincing. From our charter: "The CFRG serves as a bridge between theory and practice, bringing new cryptographic techniques to the Internet community and promoting an understanding of the use and applicability of these mechanisms via Informational RFCs". We have an opportunity to promote the understanding, use, and applicability of newer ECC mechanisms, and I hope that we do so. I woud not say we have the "onus" to do so, but if CFRG does anything in this area, it should do what its charter says. > Furthermore, CFRG owes Paul nothing. While I would be happy to review > such a document for accuracy, I have no obligation to review or > produce such a document, and the same holds for all the members of the > CFRG. I can just as easily say that Mr. Lambert has the onus to > produce such a document. > > I've changed my mind about the desirability of such a document as Mr. > Lambert wants. It would be nice if it existed, and it would be a nice > project to learn CWEB. However, I see no reason to consider the > absence of such a document a good reason to block > draft-josefsson-tls-curve25519-04. draft-josefsson-tls-curve25519-04 defines a way to use a variant of Curve25519 in TLS, by describing the differences between RFC4492 (Weierstrass ECC in TLS) and Curve25519 processing, and some differences and clarifications relative to the Curve25519 processing described in the PKC2006 publication. This is clear from the following quotes: "Private keys MUST be selected as specified in [Curve25519]. That is, private keys are 255-bits numbers with the following properties: ..." "ECPoint.point differs from the definition of public keys in [Curve25519] in two ways: ..." "Again, in line with [RFC4492] and as a departure from the convention chosen in [Curve25519], the x coordinate is converted to a byte string using big endian order. ..." "The following subsections describe the differences between using Curve25519 and the curves defined by RFC 4492 for key exchange in TLS. ... " Defining a new thing by its differences from two existing things is not the best way to get a clear and easy to implement specification. The authors could improve clarity by brining in more of the description of Curve25519, or by referencing external work such as an informational draft/RFC that describes Curve25519 (preferably the same variant as in draft-josefsson-tls-curve25519). One way that RFC6090 added clarity was by clearly separating normative references from informative ones, and relying only on a small sufficient set of normative references that were early (pre-1994). It would be good to have this sort of clarity for IETF work on Curve25519. It would be better to have a separate draft/RFC on Curve25519, as described above, because it will be clearer and more conducive to re-use of the mechanism across IETF protocols. If no separate normative document is produced, then it will be important for draft-josefsson-tls-curve25519 to incorporated a more complete description of Curve25519. Disclaimer: I have not tried to implement draft-josefsson-tls-curve25519, and I'm not claiming that it is ambiguous. The authors deserve thanks for writing this document. Our aim should be to produce clear, well-understood specifications. Not all RFC are clear or well-understood, but we don't need to emulate that precedent. David > > Sincerely, > Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Mar 5 04:56:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF261A03A6 for ; Wed, 5 Mar 2014 04:56:52 -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 JEZN8YW4RlaA for ; Wed, 5 Mar 2014 04:56:47 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE161A00A2 for ; Wed, 5 Mar 2014 04:56:46 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s25Cugwx025678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Mar 2014 13:56:42 +0100 (MET) In-Reply-To: <20140303231316.03E2E1AC37@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Wed, 5 Mar 2014 13:56:42 +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: <20140305125642.0B9871AC3E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DLfXES6THuzeJy02GPij6Co0fHY Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after Resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 12:56:53 -0000 I've just started wondering: Is the real problem acutally worse than described, and will changing the Master Secret computation actually _not_ fix the renegotiation problem? I wrote: > > The original renegotiation problem and the newly describe session resumption > problem are very similar: flawed assumptions about a cryptographic binding > that doesn't exist. But until you write down the exact properties and > think about it, you may not notice the problem. As soon as you write it > down, the problem becomes obvious. > > The abbreviated TLS handshake authenticates only the MasterSecret. > But the MasterSecret is derived exclusively from ClientHello.random, > ServerHello.random and the keyExchange transform, there is no cryptographic > binding to any identities that are authenticated during the TLS handshake. > > > So the fix of the abbreviated TLS handshake needs to account for the > (re-)authentication of the identities of the original full handshake, > either by modifying the MasterSecret computation or by authenticating > the original full handshake during the abbreviated TLS handshake > through a TLS extension similar to how the renegotiation_info extension > does this in the renegotiation handshake. The only "non-static" data covered by the Finished handshake messages of the abbbreviated TLS handshake (i.e. that goes into the renegotiation_info of the resumed TLS handshake are): ClientHello.random ServerHello.random ClientHello.session_id == ServerHello.session_id In particular, there is *NO* dependency on the MasterSecret, so the attack by an MitM should be possible, even if the MasterSecrets differ between the two sessions that are merged (I never had a requirement in my attack scenario that the MasterSecrets are the same; in fact I wasn't even aware that it was possible to create two SSL sessions with identical MasterSecrets & traffic keys when I described my attack). The MitM will only have to decrypt and re-encrypt the data during the original two sessions. The handshake_message hash does not "see" the encryption, it operates on the plaintext only. So it seems to me that changing the MasterSecret computation will not help. We need a TLS extension on the abbreviated TLS handshake that authenticates the original full handshake, such as the renegotiation_info from that handshake. -Martin From nobody Wed Mar 5 04:57:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69931A02AD for ; Wed, 5 Mar 2014 04:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuZepzoBIiIP for ; Wed, 5 Mar 2014 04:57:10 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 51A491A00E3 for ; Wed, 5 Mar 2014 04:57:10 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7F2CB47411; Wed, 5 Mar 2014 12:57:06 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 72FC3473F8; Wed, 5 Mar 2014 12:57:06 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 6641FFE2F2; Wed, 5 Mar 2014 12:57:06 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.104]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Wed, 5 Mar 2014 07:57:06 -0500 From: "Salz, Rich" To: David McGrew , Watson Ladd Date: Wed, 5 Mar 2014 07:57:04 -0500 Thread-Topic: [TLS] [Cfrg] Citing specs in specs Thread-Index: Ac84Y8f9L9G8U87QSj63kfrDdLiouwADl1PA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AA47B@USMBX1.msg.corp.akamai.com> References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com> <7A2637AF-5A16-404B-B7A1-49FB17D5345A@callas.org> <5317065E.1090007@cisco.com> In-Reply-To: <5317065E.1090007@cisco.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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bIv4cWCm0k09qMJ3GLrGqnMOetA Cc: Paul Lambert , "cfrg@irtf.org" , Jon Callas , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Wed, 05 Mar 2014 12:57:12 -0000 > "ECPoint.point differs from the definition of public keys in [Curve25519]= in two ways: ..." > "Again, in line with [RFC4492] and as a departure from the convention cho= sen in [Curve25519], the x coordinate is converted to a byte string using = big endian order. ..." Some of us consider this a defect in the I-D and would prefer to see an ECP= oint registry that allowed the 'native' little endian format used by 25519.= That cuts the issues of concern by 50% :) /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Wed Mar 5 05:08:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2298B1A02AD for ; Wed, 5 Mar 2014 05:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 dvaS5bniLN1i for ; Wed, 5 Mar 2014 05:07:47 -0800 (PST) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id EC6B21A0121 for ; Wed, 5 Mar 2014 05:07:46 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id lg15so964879vcb.26 for ; Wed, 05 Mar 2014 05:07:43 -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=iwMXsu62UJNQzSA6kMc9Gppn2xDviNXRBcjAAidlpRc=; b=HoUPYjBmWanWNCJR15U/YuQvtvbKlhw1PD4CgpOONXCtzDC0v3qoG743PQl9x5aTq8 SSZHT/LBhhTCyR/xyZGXEJvkqBMwyaJHyVfOz4rn5gU18AP/z5GjRQuRgTWWVT1mGvWQ HKrdmewujyM+ZQFpWdvvr9eEb1FaLt8SncbOlq6+3y5ejz1Xr40LJ4aJb/HTVI2f8Agp rjF4VLTvWetwPSve7hyD3S4Ok+SUWQlNDbq6LC5Dmo0Xgk8aPOSpsg9AM1Muhqq05D7n Tb7+ZGvmdui2DPZ0D6+qErYohFPqytGh561S1iK6ofJNX/gyA67ju+AbHq3hktRSdr6S Faig== 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=iwMXsu62UJNQzSA6kMc9Gppn2xDviNXRBcjAAidlpRc=; b=mST1sAYfqvDH0f1k8BMhGD5dZzpWr1f3y3zjjLt5VE1VGfD/0h5wPSQCGFB76JeRRw BRMHOGmH+bdveG6yfjzqHdV51Eoti5ucecNEzSMQpMQTHYliODrARbnhrA4UrXQU/Cfp KFa9nmndvMtnfwXt4+0Azuchr5QPr+XubnVjec3b6QYhCClDH6PVCk8cjLV5J3XmxyhL YGoz6piNL0C8IOPDRt0mqmBVkFo3CwW8sTKoLc0LKqHCnnxHNb/hTOXQPN725t8dJTnp OJNBZMwWFaCXhWLmhK7DXg7DJey+JWslmfDrZs6tIFWpAlQaUs+P1yDBW8RGPqCbTRRV so3A== X-Gm-Message-State: ALoCoQnioPqk49qRF2FsHZWRbW77a6fknRoaN4CN/HUPlZ9yq8X7bY1j9bI9e1y+aHkEm/whZJgOSScwezwnYy0gXa7rI8zGQkya7mZl5AE8pClSkaw8dIWdD3e7v0GdfdMSM7ZP5UVDk8EeEjhmhFbgaGpsWtAExBCvr+LI61xRlKbWat5wTLJywxkoPOlSh8nFQoWVJjV8 X-Received: by 10.58.45.100 with SMTP id l4mr264516vem.48.1394024863107; Wed, 05 Mar 2014 05:07:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Wed, 5 Mar 2014 05:07:22 -0800 (PST) In-Reply-To: <20140304195610.7AF1F1AC3B@ld9781.wdf.sap.corp> References: <20140304195610.7AF1F1AC3B@ld9781.wdf.sap.corp> From: Adam Langley Date: Wed, 5 Mar 2014 08:07:22 -0500 Message-ID: To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SrZ5Cl6HoJ87qkg2PNiaRmifjRk Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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: Wed, 05 Mar 2014 13:07:49 -0000 On Tue, Mar 4, 2014 at 2:56 PM, Martin Rex wrote: > A while ago I noticed that it was possible to resume a TLS session > originally established with https://www.google.com/ when proposing > that session for resumption to https://docs.google.com/ (not using > any TLS extension here, neither SNI or TLS session tickets). Yes, both of these services are terminated by the same frontend machines and they shared a session cache. Completely unrelated to this matter, you should find that's no longer the case. Sessions for www.google.com should no longer be resumable for docs.google.com. Cheers AGL From karthik.bhargavan@gmail.com Wed Mar 5 05:08:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818721A006B for ; Wed, 5 Mar 2014 05:08:04 -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 Pz6XPFuzmdcs for ; Wed, 5 Mar 2014 05:08:03 -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 D07D91A04C1 for ; Wed, 5 Mar 2014 05:07:59 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id oy12so987216veb.26 for ; Wed, 05 Mar 2014 05:07:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8Ll9fw2JzvmqVrD+BUW3EnIPDms/Y19cWWeEa7ewSp0=; b=ZZz3vFkxH1ksGej3mIcOHSgkXPAa/CetZbB9RHb/oIm4aYMZX+FE89Xg5rjgov/9SX FwVlQj64YWoDPEWoHFWcqPlOa1qq0ExSZlJEG62Apd9otVX41ooUa9vVokCV6giSLNjJ WD+UiabRPqJj1W13KHHSUE04GtHZncyZr/zGGD/x69WnD3d7HwSq9yK1a3pOEuUXh8Sn kyT16tGu02kmnalEgBoY/UPWOqcY9niYP64o5iLqNf99Vkrn7Bi9oUubhCQt9/qn3EmM Pk985fMtWwTA27Qltts7bW47IC+/Zq/KHZk88SpZX5dGxCBZvU1CPhbpYbaZqXdV848V U6Xg== X-Received: by 10.52.69.146 with SMTP id e18mr3633844vdu.15.1394024876128; Wed, 05 Mar 2014 05:07:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.96.195 with HTTP; Wed, 5 Mar 2014 05:07:36 -0800 (PST) In-Reply-To: <20140305125642.0B9871AC3E@ld9781.wdf.sap.corp> References: <20140303231316.03E2E1AC37@ld9781.wdf.sap.corp> <20140305125642.0B9871AC3E@ld9781.wdf.sap.corp> From: Karthik Bhargavan Date: Wed, 5 Mar 2014 14:07:36 +0100 Message-ID: To: mrex@sap.com Content-Type: multipart/alternative; boundary=20cf3071cd0e8cc04804f3dbb5a6 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2OaoYQx1PEM1kViktKqDZYJ1kRM X-Mailman-Approved-At: Wed, 05 Mar 2014 05:11:37 -0800 Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after 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: Wed, 05 Mar 2014 13:10:31 -0000 --20cf3071cd0e8cc04804f3dbb5a6 Content-Type: text/plain; charset=ISO-8859-1 > The only "non-static" data covered by the Finished handshake messages of > the abbbreviated TLS handshake (i.e. that goes into the renegotiation_info > of the resumed TLS handshake are): > > ClientHello.random > ServerHello.random > ClientHello.session_id == ServerHello.session_id > Renego Indication uses the client and server verify data: verify_data = PRF(master_secret, label, Hash(handshake_message) So, it is bound to the master_secret -K. --20cf3071cd0e8cc04804f3dbb5a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=
The only "non-static" data covered= by the Finished handshake messages of
the abbbreviated TLS handshake (i.e. that goes into the renegotiation_info<= br> of the resumed TLS handshake are):

=A0 =A0 ClientHello.random
=A0 =A0 ServerHello.random
=A0 =A0 ClientHello.session_id =3D=3D ServerHello.session_id

Renego Indication uses the client and server verify data:
verify_data =3D PRF(master_secret, label, Hash(handshake_message)

<= /div>
So, it is bound to the master_secret

-K.
--20cf3071cd0e8cc04804f3dbb5a6-- From karthik.bhargavan@gmail.com Wed Mar 5 05:09:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9A31A0450 for ; Wed, 5 Mar 2014 05:09:47 -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 GYs8ebqwuZqZ for ; Wed, 5 Mar 2014 05:09:45 -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 5C8C71A006B for ; Wed, 5 Mar 2014 05:09:45 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id id10so984686vcb.13 for ; Wed, 05 Mar 2014 05:09: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:from:date:message-id:subject:to :content-type; bh=J52s7TVA/u54ihzCpIgdjUcebcW3p3NJhQunnyzKZsQ=; b=aeCWooKGEhRSgXskkQGCvKqqPDUHHSsP7w5fK6hdimt8ObCoF2O4r62WSWQ3p2R9Ht icEU9YnR6LQPBezMdbrmJ9VqKoZZ732BYdc+QmXX5k3Af4BQk0QyfAREszHtxWK2p8Ly pC5EnEa7m1GTTfFMAU9QkgUmslNyN7KU3TpBysbT+joCwcLehEvs3fG2C8XoevzVQcW6 YNFlC9FHc/0OzOTXnlRZhe5UOpHsZsLqhrYEDUNzEfUM3MXCz5rHextERinN60UBiDS2 TPlVoKfbZ44v5CNwVu/1UgCOE7WI6VaRfbxULdTBY1qjFgQ1qddPbUrl8qZLE+3BZSLz awJw== X-Received: by 10.220.48.194 with SMTP id s2mr95891vcf.43.1394024981686; Wed, 05 Mar 2014 05:09:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.96.195 with HTTP; Wed, 5 Mar 2014 05:09:20 -0800 (PST) In-Reply-To: <5316A363.3000801@Vimino.COM> References: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> <5315DD23.30901@drh-consultancy.co.uk> <5315F9BA.4060805@drh-consultancy.co.uk> <5316A363.3000801@Vimino.COM> From: Karthik Bhargavan Date: Wed, 5 Mar 2014 14:09:20 +0100 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11c1e7fcd76e9a04f3dbbb23 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Mm2lGQ7oOaOQwvES-cmGThgDFww X-Mailman-Approved-At: Wed, 05 Mar 2014 05:11:37 -0800 Subject: Re: [TLS] MITM Attacks on Client Authentication after 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: Wed, 05 Mar 2014 13:10:32 -0000 --001a11c1e7fcd76e9a04f3dbbb23 Content-Type: text/plain; charset=ISO-8859-1 After my talk at the meeting, its worth summarizing comments on the triple handshake attack and its impact on client-authenticated TLS renegotiation. In the common case (e.g HTTPS) where a server presents a certificate in both the initial handshake and during renegotiation, it would be enough for the client to verify that the certificate doesn't change. (More precisely, the client needs to verify that the principals represented by both certificates are equally trustworthy.) There are other cases, and I'd be curious to know how common they are, when one or both handshakes does not have a server certificate. These would be more difficult to fix with a general TLS library-level policy. Typical examples (from discussion at the meeting): - Initial handshake uses DH_anon or a self-signed server cert and renegotiation uses the real server certificate - Initial handshake uses a server certificate, and renegotiation uses PSK or SRP to authenticate the user In the first case, I guess the purpose is to protect the server name from passive attackers. In the second, the purpose is privacy for the user's SRP/PSK identity. In both cases, if both handshakes happen on the same connection, RFC5746 (renego indication) gives us a pretty strong guarantee that the principals on both ends do not change. In effect, the second handshake retroactively authenticates the first. The triple handshake attack shows that this nice guarantee does not hold if there is session resumption between the two handshakes. I can't think of easy implementation-level ways of fixing the DH_anon and PSK/SRP cases. Best, Karthik On Wed, Mar 5, 2014 at 5:09 AM, Xuelei Fan wrote: > On 3/5/2014 12:05 AM, Dr Stephen Henson wrote: > >> On 04/03/2014 15:23, Martin Thomson wrote: >> >>> On 4 March 2014 14:03, Dr Stephen Henson >>> wrote: >>> >>>> >>>> I performed a few checks with an experimental option to change the >>>> server >>>> certificate during renegotiation, which I believe simulates the attack >>>> mechanism. If the client checks certificates in band then all versions >>>> choke >>>> with a verification error if a chain is untrusted. For 1.0.2 only it >>>> also chokes >>>> if the chain is trusted but the hostname doesn't match. >>>> >>> >>> This is an interesting option. I like the general idea, but wonder >>> what "hostname doesn't match" means in this case. >>> >>> JSSE enabled the hostname checking during handshaking for HTTPS and > LDAP. If hostname doesn't match, the handshaking is terminated immediately. > > > I'd be interested if anyone knows of examples where the server >> certificate does >> have to change during renegotiation and how common that practice is. >> >> I was wondering, if the cipher suite is changed from RSA cert based to > EC cert based (and vice versa), the server certificate would have to change > accordingly. Not sure about the case in practice. > > Xuelei > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c1e7fcd76e9a04f3dbbb23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
After my talk at the meeting, its= worth summarizing comments on the triple handshake attack and its impact o= n client-authenticated TLS renegotiation.

In the common case (= e.g HTTPS) where a server presents=A0 a certificate in both the initial han= dshake and during renegotiation, it would be enough for the client to verif= y that the certificate doesn't change. (More precisely, the client need= s to verify that the principals represented by both certificates are equall= y trustworthy.)

There are other cases, and I'd be curious to know how common = they are, when one or both handshakes does not have a server certificate. T= hese would be more difficult to fix with a general TLS library-level policy= .

Typical examples (from discussion at the meeting):

-= Initial handshake uses DH_anon or a self-signed server cert
=A0 and ren= egotiation uses the real server certificate
=A0
- Initial handshake uses a server certificate,
=A0 and r= enegotiation uses PSK or SRP to authenticate the user=A0
In the first case, I guess the purpose is to protect the server name from= passive attackers. In the second, the purpose is privacy for the user'= s SRP/PSK identity.

In both cases, if both handshakes happen on the same connect= ion, RFC5746 (renego indication) gives us a pretty strong guarantee that th= e principals on both ends do not change. In effect, the second handshake re= troactively authenticates the first.

The triple handshake attack shows that this nice = guarantee does not hold if there is session resumption between the two hand= shakes.

I can't think of easy implementation-level wa= ys of fixing the DH_anon and PSK/SRP cases.

Best,
Karthik



On Wed, Mar 5, 2014= at 5:09 AM, Xuelei Fan <xuelei.fan@vimino.com> wrote:
On 3/5/2014 12:05 AM, Dr Stephen Henson= wrote:
On 04/03/2014 15:23, Martin Thomson wrote:
On 4 March 2014 14:03, Dr Stephen Henson <lists@drh-consultancy.co.uk> wrot= e:

I performed a few checks with an experimental option to change the server certificate during renegotiation, which I believe simulates the attack
mechanism. If the client checks certificates in band then all versions chok= e
with a verification error if a chain is untrusted. For 1.0.2 only it also c= hokes
if the chain is trusted but the hostname doesn't match.

This is an interesting option. =A0I like the general idea, but wonder
what "hostname doesn't match" means in this case.

JSSE enabled the hostname checking during handshaking for HTTPS and LDAP. = =A0If hostname doesn't match, the handshaking is terminated immediately= .


I'd be interested if anyone knows of examples where the server certific= ate does
have to change during renegotiation and how common that practice is.

I was wondering, if the cipher suite is changed from RSA cert based to EC c= ert based (and vice versa), the server certificate would have to change acc= ordingly. =A0Not sure about the case in practice.

Xuelei


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

--001a11c1e7fcd76e9a04f3dbbb23-- From nobody Wed Mar 5 05:30:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4C51A00AE for ; Wed, 5 Mar 2014 05:30:02 -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 FGjjfBGt5NRa for ; Wed, 5 Mar 2014 05:29:59 -0800 (PST) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7177A1A002A for ; Wed, 5 Mar 2014 05:29:59 -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 24F46603CD for ; Wed, 5 Mar 2014 13:29:55 +0000 (GMT) Message-ID: <5317267F.1070909@akr.io> Date: Wed, 05 Mar 2014 13:28:31 +0000 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161BA7.3070405@drh-consultancy.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iCqMSQNCJrgaXia_wU_c-VpLXnA Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Mar 2014 13:30:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 (Just popping by briefly on this one.) On 04/03/2014 18:56, Adam Langley wrote: > I feel this is a problem that FIPS needs to sort out (they don't > have a concept of an AEAD, I assume). I'm unwilling to have the > whole world waste bandwidth, and have a more dangerous > specification, because of a bureaucratic problem. A strong +1 on this. Random IVs risk collision earlier, burn valuable entropy faster, and are far more fragile. Sequential IVs are deterministic, verifiable, debuggable, and implicit. It is crystal-clear to me that sequential IVs are the correct approach. I would be interested to hear NIST's reasons for recommending otherwise. ChaCha20 and Poly1305 are, of course, not in the FIPS catalogue, so it's moot. In a wider sense, given recent discoveries about extremely critical parts of widely-used TLS stacks, perhaps limiting the scope of reviews to crypto primitives would be unwise in any event: certified crypto doesn't do any good when it's skipped over. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTFyZ+AAoJEOyEjtkWi2t6uyIP/3Gl18noWkYo28+1WQ6qFxAG L0t30TiMSTxZpRsMH5Z21wrrYvNb+5R9Pv3RqBVNMl6Svhz5u3HAqLvXQf1qtZr5 z5C6qejElVGKBFapkdl8QZ6WKn2PLUfF0/elCc9OPfL9WBRousEB8UTOVQ73Hfut kkLTdk2FTJUGnt2DaZwInvUQFqjdC3uvMq2/pyUUL4RTmckc3h5LCET4nBpYdZAJ Oq2XLIKzdIrtDQVHPYq2xLs+Ul6/CZPkp4/h9/zOIKxSK/XI72KYxc5H+sz+g2xz CwX8AYycs4nQ6NAQ/VgcDviIR5h8D94OUcawWrdxzstgjDadfPevLH5XPZOnDBAw TTEiNkzpaqTwm24++bf/MhC5ZEH6MktBXUyUl6rN0zwc7vcNBOFNs5rxCbpD+Di2 wQdZbUj9Tanh3yn5upWKDC6rt4sPYmdF/Mhv6YM1LP3H4JpVziHPozj24wUVkXuO 6FDLbJxTSOHwRmQzQ5vgtOBHzDz9af7kCq9fKEwoH5Dv21lYI/X3fvWuLjW3Nqya CI9+or1uN2qKDgTWfhGrj42Iu3PVJ/zpR77UqcYPElezacKHvrD7vJbYeU9XeCkE yHE6qoIyDLLa5QWkQoBPF1C7bwATaJfXB5Zj3QZ4qXwU/ZyJju6HS07wUEaXRS8g mZoa6PrFjSGwwWTZ1YzS =/uMb -----END PGP SIGNATURE----- From nobody Wed Mar 5 05:39:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC63E1A0165 for ; Wed, 5 Mar 2014 05:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 t_lbQ46fuMuv for ; Wed, 5 Mar 2014 05:39:07 -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 4FEA21A0137 for ; Wed, 5 Mar 2014 05:39:07 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id lc6so542204vcb.7 for ; Wed, 05 Mar 2014 05:39:03 -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=ImAz8Vi9EmPcdSX6dGi2aeu1Giiyx37xWCgfDl2KFDw=; b=hpYpYwySODGVd5jN6Z2pCjrf+UAv0uaEAE23c2lTjEBr4S3elv4Rn0xHgbtpboOVA9 QieuS8c3hbBILYa5kQFjAproPgmoLiUkWrA1D7UeKBfESmalnAziJmbFO8zUkodh9xOo 1kthX8iJlW2BSuVzkbLB9FFlYbOD+kcFhZUmHHo0bssK1INnYomcoeOcRGkpQO77kBI0 lCpNvcOTJZgB/3Z+uvUk6PPVf3v1E8vzQlQ/ZtFplVSQaK4kWHwDoPzoC2SVIPwCpiU8 7E+HvnEDrcT7xdq49IMznLjAdRG5gqGkMOl93JL7rGjEmmk6Uv/RdrcGWLdqXynk64ft yuhw== 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=ImAz8Vi9EmPcdSX6dGi2aeu1Giiyx37xWCgfDl2KFDw=; b=R9fzanNWJJk4MiCJlUPoqPPkqcAwwxqo89SpXbpmbYSS1nxtwp7+fFUp9ZJDedJJMp tXXUeqWtchZPh8/B/Sdov5Unq/ClxKAz45DeYpzRir0nmqh2M4n9v2CP3Dk2JeM6AlLZ 0n8WBQxO2tvI453arF+WWnb8BjwiacqLTHJAKQ9TSMBql4gHTH03Clk5V71ry26Nxcee L8FpDG2Mj8mDNS1/8Dlal8C6stjsPolQsoYddjjQBpACeo2JTDBsU4h3EtKvzX72gu8o jZrubAuW86a130YQfUH1RXuP+lkVGcVy1PrGpColrUSUeFyjNNrnCIZElOgcPU/DdcQd 9rYQ== X-Gm-Message-State: ALoCoQn348blKRRwvNyLgNQHGEXy7b3RTHR4GnTknXEE1yaiaJtpQe2gNi3QRhnzZTtaoX9EGIlBD/uVh+vHeE5P5BRKbH9AxMf2qwh70W6boHBug4aYrX25C7A21ZWxb6KvgaAnLpcSROw1aJ8RyjD4laMIBBLYBBXgEP+IIinhinA0yxvG8ZzOFTCp73Wri+HHHbnq1D1B X-Received: by 10.52.250.236 with SMTP id zf12mr3726210vdc.9.1394026743476; Wed, 05 Mar 2014 05:39:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Wed, 5 Mar 2014 05:38:43 -0800 (PST) In-Reply-To: <5317267F.1070909@akr.io> References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161BA7.3070405@drh-consultancy.co.uk> <5317267F.1070909@akr.io> From: Adam Langley Date: Wed, 5 Mar 2014 08:38:43 -0500 Message-ID: To: Alyssa Rowan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wrStSbKB_4GYjUgHj279_Rhm_1E Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Mar 2014 13:39:09 -0000 On Wed, Mar 5, 2014 at 8:28 AM, Alyssa Rowan wrote: > It is crystal-clear to me that sequential IVs are the correct > approach. I would be interested to hear NIST's reasons for > recommending otherwise. I don't believe that NIST actually *is* recommending random nonces. The explicit nonce form allows for it, however, and that's why I characterise it as "dangerous". I believe the motivation for wanting an explicit nonce is so that the nonce management is contained "within" the AEAD. The AEAD then, conceptually, returns a ciphertext block that includes the explicit nonce as a prefix and thus, by considering the AEAD 'module' in isolation, one can ensure that it doesn't duplicate nonces. (Any such AEAD 'module' would need to use a counter internally when the nonces are only 8 bytes for the reasons that you give.) I think the disagreement is whether this conceptual partitioning is worth the danger and overhead. (I'm claiming that it's not.) Cheers AGL From nobody Wed Mar 5 05:41:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158E91A017A for ; Wed, 5 Mar 2014 05:41:01 -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 bzZZxb6IV15V for ; Wed, 5 Mar 2014 05:40:59 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id CF48C1A0171 for ; Wed, 5 Mar 2014 05:40:58 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s25Derie015811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Mar 2014 14:40:53 +0100 (MET) In-Reply-To: To: Karthik Bhargavan Date: Wed, 5 Mar 2014 14:40:53 +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: <20140305134053.4479B1AC3E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/A1L6ZuVbRzw2kOPnoUpESkf-vu8 Cc: "tls@ietf.org" Subject: Re: [TLS] MITM Attacks on Client Authentication after Resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 13:41:01 -0000 Karthik Bhargavan wrote: > > The only "non-static" data covered by the Finished handshake messages of > > the abbbreviated TLS handshake (i.e. that goes into the renegotiation_info > > of the resumed TLS handshake are): > > > > ClientHello.random > > ServerHello.random > > ClientHello.session_id == ServerHello.session_id > > > > Renego Indication uses the client and server verify data: > > verify_data = PRF(master_secret, label, Hash(handshake_message) > > So, it is bound to the master_secret *Blush* You're correct. I'm sorry for the confusion. -Martin From nobody Wed Mar 5 05:47:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38761A03D8 for ; Wed, 5 Mar 2014 05:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVLk8WV0jwMG for ; Wed, 5 Mar 2014 05:47:29 -0800 (PST) Received: from claranet-outbound-smtp03.uk.clara.net (claranet-outbound-smtp03.uk.clara.net [195.8.89.36]) by ietfa.amsl.com (Postfix) with ESMTP id A32761A0072 for ; Wed, 5 Mar 2014 05:47:29 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:54879 helo=[192.168.7.9]) by relay13.mail.eu.clara.net (relay.clara.net [81.171.239.33]:10465) with esmtpa (authdaemon_plain:drh) id 1WLCAN-0008WE-BC for tls@ietf.org (return-path ); Wed, 05 Mar 2014 13:47:23 +0000 Message-ID: <53172AE6.1000300@drh-consultancy.co.uk> Date: Wed, 05 Mar 2014 13:47:18 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161BA7.3070405@drh-consultancy.co.uk> <5317267F.1070909@akr.io> In-Reply-To: <5317267F.1070909@akr.io> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tUq7DU7yAMrdFJeRpdo_4WeQvIY Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Mar 2014 13:47:32 -0000 On 05/03/2014 13:28, Alyssa Rowan wrote: > > Random IVs risk collision earlier, burn valuable entropy faster, and are > far more fragile. > > Sequential IVs are deterministic, verifiable, debuggable, and implicit. > > It is crystal-clear to me that sequential IVs are the correct approach. I > would be interested to hear NIST's reasons for recommending otherwise. > In the case of AES-GCM the relevant FIPS specifications *do* permit sequential IVs. One permitted construction is a random starting point generated within the module which is then incremented on each invocation. That "random starting point" requirement means you can't use the sequence number directly though. One way round that would be to have a way to specify the starting point. An explicit IV in the first record for example, but that looks messy to me. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nobody Wed Mar 5 09:25:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E731A01A7 for ; Wed, 5 Mar 2014 09:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 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, HELO_EQ_DE=0.35, HTML_MESSAGE=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 eWFWMf3cvtkV for ; Wed, 5 Mar 2014 09:25:30 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) by ietfa.amsl.com (Postfix) with ESMTP id CDD911A00F5 for ; Wed, 5 Mar 2014 09:25:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1394040325; l=2168; s=domk; d=sandeep.de; h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To: MIME-Version:X-RZG-CLASS-ID:X-RZG-AUTH; bh=JZLVkHUTffHJU2qoW+b+xbbgj2I=; b=Q6HJ0ICHES2f7XgT1dxrjIVmm9coL1fWA/qs9iodX0tW74ZsfiqZytcXuJSzD+ChIUd pYfpXunNC+m4n9mlvkUbWvyXMGPJnSN52kJh6f92IyAjJ9snpbxgen4HReYikY/EdFWoD DodwMjW2UVIHqr7K62iNfEfoIGvR9nQsKBg= X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkNEKLhUifTGcaF4Qcnm8= X-RZG-CLASS-ID: mo00 Received: from mail-qg0-f43.google.com ([209.85.192.43]) by smtp.strato.de (RZmta 32.27 AUTH) with ESMTPSA id Y0770bq25HPOfBc (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verification FAILED - certificate not trusted)) (Client hostname not verified) for ; Wed, 5 Mar 2014 18:25:24 +0100 (CET) Received: by mail-qg0-f43.google.com with SMTP id f51so3743596qge.2 for ; Wed, 05 Mar 2014 09:25:23 -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=RDNeslT6UqV/0z2nwlxg6TpsYyjuyofEZ5w92qxETr0=; b=O1mujqHzxgJdfhRhrjCSlhCVxptv+mlD3uwzDiWoDhP5i/Cyis1CYsmvn7rD9GwX01 ZcR06B9D63wX6MbyB7+mmFUm7qZAfmeBsNww0+5PLYeKkyvFmai4JVqi3Tkw/cJd/yXn 71lxV1BROu2Rwr6m8E2IzAUH9HZlwQMMufWav8HrdGqC1dcaYpOjb6B2lTZT+wTzWdBY IcZG0eLfLSMueNcnMg1TRh5BPJg7nwOxkG5zeMNZeJ7Fkw+eM+lNTMCQfeiY3geOruMZ 6Lx03/tyFtLV1nFSZvwD83YgypxPE+L6BHcli2T/RjFvKTKJaRMoxWJ/qIezA0DQbvBV MIuw== MIME-Version: 1.0 X-Received: by 10.224.0.79 with SMTP id 15mr8543265qaa.2.1394040323318; Wed, 05 Mar 2014 09:25:23 -0800 (PST) Received: by 10.224.32.73 with HTTP; Wed, 5 Mar 2014 09:25:23 -0800 (PST) In-Reply-To: References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161BA7.3070405@drh-consultancy.co.uk> <2A0EFB9C05D0164E98F19BB0AF3708C711EFC395B0@USMBX1.msg.corp.akamai.com> Date: Wed, 5 Mar 2014 18:25:23 +0100 Message-ID: From: Sandeep Kumar To: Adam Langley Content-Type: multipart/alternative; boundary=047d7bf0d498462a6a04f3df4e12 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XGMAFkmpYxio6SP0lSTAp5BQ7Do Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Mar 2014 17:25:32 -0000 --047d7bf0d498462a6a04f3df4e12 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 5, 2014 at 12:18 AM, Adam Langley wrote: > On Tue, Mar 4, 2014 at 6:11 PM, Salz, Rich wrote: > > For eight bytes. Shrug, okay, your battle (if, in fact, it is; Wan-Teh > could be rightr). > > 8 bytes is ~0.6% of bandwidth assuming that one is sizing records to > packets. It's not huge, but it's not trivial. > > For constrained environments where we try to fit everything within a 127 byte of the 802.15.4 frame to avoid fragmentation, 8 bytes of additional IV is going to be a deal breaker for this cipher suite to be used in DTLS for such environments. Prefer there is no such unnecessary ciphertext expansion. Sandeep --047d7bf0d498462a6a04f3df4e12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 5, 2014 at 12:18 AM, Adam Langley <= ;agl@google.com>= wrote:
On Tue, Mar 4, 2014 at 6:11 PM, Salz, Rich <rsalz@akamai.com> wrote:
> For eight bytes. =A0Shrug, okay, your battle (if, in fact, it is; Wan-= Teh could be rightr).

8 bytes is ~0.6% of bandwidth assuming that one is sizing records to<= br> packets. It's not huge, but it's not trivial.


For constrained environment= s where we try to fit everything within a 127 byte of the 802.15.4 frame to= avoid fragmentation, 8 bytes of=A0additional IV is going to=A0be a deal br= eaker for this cipher suite to be used in DTLS for such environments. Prefe= r there is no such unnecessary ciphertext expansion.
=A0
Sandeep
--047d7bf0d498462a6a04f3df4e12-- From nobody Wed Mar 5 09:43:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BDD1A053B for ; Wed, 5 Mar 2014 09:43:54 -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 VN5pBa0WwkIE for ; Wed, 5 Mar 2014 09:43:51 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan7.extendcp.co.uk [79.170.43.71]) by ietfa.amsl.com (Postfix) with ESMTP id 313361A0663 for ; Wed, 5 Mar 2014 09:43:51 -0800 (PST) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan5.hi.local) by mailscan-g67.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1WLFr8-0004vz-Qp for tls@ietf.org; Wed, 05 Mar 2014 17:43:46 +0000 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan5.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1WLFr3-0003Vv-Hq for tls@ietf.org; Wed, 05 Mar 2014 17:43:41 +0000 Received: from host86-156-114-243.range86-156.btcentralplus.com ([86.156.114.243] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1WLFr3-0004GW-0D for tls@ietf.org; Wed, 05 Mar 2014 17:43:41 +0000 Message-ID: <53176278.7040902@gridmerge.com> Date: Wed, 05 Mar 2014 17:44:24 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161BA7.3070405@drh-consultancy.co.uk> <5317267F.1070909@akr.io> <53172AE6.1000300@drh-consultancy.co.uk> In-Reply-To: <53172AE6.1000300@drh-consultancy.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010504060607070703000102" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aHy1YIW9FSoHAAEyHrKyr1_EbAw Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 17:43:54 -0000 This is a cryptographically signed message in MIME format. --------------ms010504060607070703000102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable This seems to be a non-issue to me. In SP 800-38D section 8.2.1, the=20 deterministic construction is described using an IV with an invocation=20 field. If the invocation field is specified as an integer counter, it=20 will, by definition, increment by one every time the AES-GCM encrypt=20 function is invoked for a particular key. Maybe I missed it, but I=20 didn't notice the requirement that the invocation field starts at a=20 random starting point? Therefore, this could start at 0 on provision of=20 a new key and also be the basis of the sequence number. If there is=20 insistence that this is generated within a cryptographic module for=20 validation purposes, in the TLS case, the module would use the=20 deterministic construction with the invocation field as an integer=20 counter and export the invocation field to form the TLS sequence number. = In this way, there would be no need to have to supply any additional=20 code as part of the validation. Robert On 05/03/2014 1:47 PM, Dr Stephen Henson wrote: > On 05/03/2014 13:28, Alyssa Rowan wrote: >> Random IVs risk collision earlier, burn valuable entropy faster, and a= re >> far more fragile. >> >> Sequential IVs are deterministic, verifiable, debuggable, and implicit= =2E >> >> It is crystal-clear to me that sequential IVs are the correct approach= =2E I >> would be interested to hear NIST's reasons for recommending otherwise.= >> > In the case of AES-GCM the relevant FIPS specifications *do* permit seq= uential > IVs. One permitted construction is a random starting point generated wi= thin > the module which is then incremented on each invocation. > > That "random starting point" requirement means you can't use the sequen= ce > number directly though. > > One way round that would be to have a way to specify the starting point= =2E An > explicit IV in the first record for example, but that looks messy to me= =2E > > Steve. --------------ms010504060607070703000102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDAzMDUxNzQ0MjRaMCMGCSqGSIb3DQEJBDEWBBS3M7VnMZ8ujUQA8jrSDFkY6P1OLTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAClqQsFSj3t7MMXzQJrAfa6BJuCSOfBn2o+SPTAdxSQIBbcN qlx6YAQQS45m4GcA7e3XPwuLmguXlAGFHXV1CzC/PoLcob8ep64oLkEJuA5ACls5vFFqbHkT tQjLLMRN1sPQDJ5cVS7ZP6GH+LxNi6LL1SPhNZI0v6OtMQP7AqsxqAEHFFnz3vGYkx7EVVJh WIrPWiQz8fSVlMPQFz4CsRGZ2x1j5fNmDtHwsocHinB3sU4F4pkAvLp3VC+n5fmZ/uPtIOik q3mmQf6RQ68gSTz0888BRSgiWW+btfREi0DdgzIIZT7DzKVnDWzZdpsWKITu4Fqpdl2zES+s rB13POYAAAAAAAA= --------------ms010504060607070703000102-- From nobody Wed Mar 5 10:45:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC2B1A011E for ; Wed, 5 Mar 2014 10:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShtLHyzOYtu2 for ; Wed, 5 Mar 2014 10:45:34 -0800 (PST) Received: from claranet-outbound-smtp07.uk.clara.net (claranet-outbound-smtp07.uk.clara.net [195.8.89.40]) by ietfa.amsl.com (Postfix) with ESMTP id A684B1A01DD for ; Wed, 5 Mar 2014 10:45:33 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:24318 helo=[192.168.7.9]) by relay17.mail.eu.clara.net (relay.clara.net [81.171.239.37]:10465) with esmtpa (authdaemon_plain:drh) id 1WLGon-0006nT-PK for tls@ietf.org (return-path ); Wed, 05 Mar 2014 18:45:25 +0000 Message-ID: <531770C1.3090509@drh-consultancy.co.uk> Date: Wed, 05 Mar 2014 18:45:21 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161BA7.3070405@drh-consultancy.co.uk> <5317267F.1070909@akr.io> <53172AE6.1000300@drh-consultancy.co.uk> <53176278.7040902@gridmerge.com> In-Reply-To: <53176278.7040902@gridmerge.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XapZMv2S07hVmCQ37anzQf4zN54 Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Mar 2014 18:45:36 -0000 On 05/03/2014 17:44, Robert Cragie wrote: > This seems to be a non-issue to me. In SP 800-38D section 8.2.1, the > deterministic construction is described using an IV with an invocation field. If > the invocation field is specified as an integer counter, it will, by definition, > increment by one every time the AES-GCM encrypt function is invoked for a > particular key. Maybe I missed it, but I didn't notice the requirement that the > invocation field starts at a random starting point? Therefore, this could start > at 0 on provision of a new key and also be the basis of the sequence number. If > there is insistence that this is generated within a cryptographic module for > validation purposes, in the TLS case, the module would use the deterministic > construction with the invocation field as an integer counter and export the > invocation field to form the TLS sequence number. In this way, there would be no > need to have to supply any additional code as part of the validation. > SP800-38D is combined with the FIPS 140-2 implementation guidance (IG) during FIPS 140-2 validation. In this case IG A.5 is relevant for AES-GCM and IVs. The IG can modify the requirements of other standards (e.g. restrict them) for the purposes of FIPS 140-2. A deterministic IV from SP800-38D 8.2.1 looks like it falls under IG A.5 3.A: "A. Each deterministically established IV shall include an encoding of the modules name and the name shall be long enough to allow for at least 32^2 different names." Which presumably isn't something we'd do for TLS. There is of course some guesswork involved here in that any future FIPS spec and IG would be similar to that for AES-GCM. In the case of AES-CCM there aren't any IV internal generation requirements AFAIK. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From SRS0=caPd=YH=acm.org=bmoeller@srs.kundenserver.de Wed Mar 5 16:35:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78F51A0010 for ; Wed, 5 Mar 2014 16:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 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.547, 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 bYwtQoll6QXl for ; Wed, 5 Mar 2014 16:35:07 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.130]) by ietfa.amsl.com (Postfix) with ESMTP id 635B61A0004 for ; Wed, 5 Mar 2014 16:35:07 -0800 (PST) Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) by mrelayeu.kundenserver.de (node=mreue001) with ESMTP (Nemesis) id 0MeXgF-1WYnDl2CoZ-00QDmS; Thu, 06 Mar 2014 01:35:02 +0100 Received: by mail-yh0-f42.google.com with SMTP id a41so1990519yho.1 for ; Wed, 05 Mar 2014 16:35:01 -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=pO1szNZkFLZcEvglMPP8CG+ZaJn9ZvSPCHiFzHBMi00=; b=Od7YOnaacPmuWPTwIalh+gQn5mxvEn2QmNMw2BqQd64XVk1yqp3bp6Ec3Bt3XHy6RI i4EZtgRK3W0GXeSkTZCFVQSAMn5fLSqAI3SSr2KHeFkj9Ta7eFr4pny0CoyZB18FmJWN rFhdQiECw3mHPdFBRfkN7ZbDyR22dQex+yLuNCU/1QbMzoAwAN67u3JBGHbzFKnORU2I yz++uuoq8615qQxyiqro7gG2fTX8/q3amxrdNYQvLLJRq9yP/ZvjN/SPHQLc6f3omOYA riadvPDnPlSxahbpwefF7iCnpU2ujN2G76GPqmUsN6R+Gz1Sior9z0kRHv4DxI5bKal0 NNUw== MIME-Version: 1.0 X-Received: by 10.236.136.231 with SMTP id w67mr10886414yhi.53.1394066101525; Wed, 05 Mar 2014 16:35:01 -0800 (PST) Received: by 10.170.78.5 with HTTP; Wed, 5 Mar 2014 16:35:01 -0800 (PST) In-Reply-To: <53161825.7060409@bbn.com> References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.com> Date: Wed, 5 Mar 2014 16:35:01 -0800 Message-ID: From: Bodo Moeller To: Stephen Kent Content-Type: multipart/alternative; boundary=20cf303bfb5cc6665e04f3e54e67 X-Provags-ID: V02:K0:ol2jpISFGGy5J3JZBbT0Ejp/eASvfFkIt/k3xSS0l4I YKDjldwepR/gskDWtPVWgu+WL7FBENKTZLIo4XDbKkGc4cj22m WG9+Whrz5dFnihQxOBeHZcSljvQaBbgDOu81Eys50FqDlu1ppz T61fOWV+edYUrEVq4AnBQfyYLwiTa4kcHtvw5YDLZPvr4J+nPQ Cmuweo9ZdX/IkzthGfaAijXy7pyfEvzb6/CvHU3GBdVHsmdTAv 6tPcVyxya8+457q9wH8QpK90L2qOL2+VYf2DhAfGAP4ewsvdwo 67Co7LTmXTmeBSWzMZIOKU5HHPKnLuPjFDYHZwfiBYwdoJlHvm bD3kQMrueaGuEgBOE5f5yQfqYf85KWB1DDznqCA5cpINik0wji 1tD7oIuhcFTz+dEe76ECW84Wv7H7NOGqpeav6oD0eDR5LVEv9M U5xBT Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rSaWLTp3AYr4QLx7IjEvbQ2hJoA Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 00:35:49 -0000 --20cf303bfb5cc6665e04f3e54e67 Content-Type: text/plain; charset=ISO-8859-1 Stephen Kent : Anyone who has had a product evaluated will > tell you that the goal is always to minimize the amount of code that is > subject > to review. If one were to use a TLS (or ESP) sequence number for an IV, > all of > the protocol code would be part of the evaluation, and that would make the > evaluation prolonged and very costly. > I suppose if this becomes an actual concern for evaluation, you could create a more easily evaluable module that accepts explicit IVs but checks that these increase monotonically between invocations. (Accepting *explicit* IVs doesn't mean you have to accept *arbitrary* IVs.) (Implicitly, this would also enforce the TLS requirement that sequence numbers are not allowed to wrap around once you're beyond 2^64 records.) --20cf303bfb5cc6665e04f3e54e67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Step= hen Kent <kent@bbn.com>:

Anyone who has had a = product evaluated will
tell you that the goal is always to minimize the amount of code that is sub= ject
to review. If one were to use a TLS (or ESP) sequence number for an IV, all= of
the protocol code would be part of the evaluation, and that would make the<= br> evaluation prolonged and very costly.

I suppose= if this becomes an actual concern for evaluation, you could create a more = easily evaluable module that accepts explicit IVs but checks that these inc= rease monotonically between invocations. =A0(Accepting *explicit* IVs doesn= 't mean you have to accept *arbitrary* IVs.)

(Implicitly= , this would also enforce the TLS requirement that sequence numbers are not= allowed to wrap around once you're beyond 2^64 records.)

--20cf303bfb5cc6665e04f3e54e67-- From nobody Wed Mar 5 16:59:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72961A0010 for ; Wed, 5 Mar 2014 16:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.903 X-Spam-Level: X-Spam-Status: No, score=0.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 6L9T9xDwoKy5 for ; Wed, 5 Mar 2014 16:59:10 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (agjbgdcfdbea.dreamhost.com [69.163.253.140]) by ietfa.amsl.com (Postfix) with ESMTP id A22841A0031 for ; Wed, 5 Mar 2014 16:59:10 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 19DA32005D106 for ; Wed, 5 Mar 2014 16:59:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=5ht+XLU6F7Faa38WQpQM 96+j374=; b=NM8ivcuKsoor2diV9IOHZwsuVrlDjRb1s/EUt868npshqqU5mQJP 41dXSERiVXD8Kb03ln0kMeocn5kaROurY770jqO/znZrxdTEot9EkWpJyVI4iC/K IhNKzkjbXFvd45Bza1L4mHn2k5qnoxPSmbX0gxF5N0k/oqc4n1Bw2p8= Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id C21062005D105 for ; Wed, 5 Mar 2014 16:59:06 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id p61so2209217wes.25 for ; Wed, 05 Mar 2014 16:59:05 -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=JBMoWZfxiHoGvDFNjLG7hXmAA6Y/BswHHdugnLxYHRM=; b=dcLWhxkNkUXonPwaJU0GjhMLR0IdD9Ghr6GlL3Pxmlm7EFAfTv60ObbD0qaw/3gJo9 DzCNCbwEwQvHelbE3aYhPeWDL3wNQpagyQPr/ZvbGeiiyGf5cXHEUdIR16l2xGLMi6GD 7VmSXOC3prHKaKjcSf7uRqVBjO8g10t4E6iTy2p9511ZxBZOR3t17iS94zOasM4BZgwo C/Qic1jZhA1fDc+HaFii/0WSqw9TF/E676ixxeLq2SUdQ6W+cq58J7hZd3go4FAPT8TX 1zKsiR1LuCeId9MM55D30twBo2Y6PEVVUwRqNaCBCnCA99FuAcMFcMQX30Nv3AQ+TMLD hfVQ== MIME-Version: 1.0 X-Received: by 10.194.250.34 with SMTP id yz2mr5682548wjc.18.1394067545415; Wed, 05 Mar 2014 16:59:05 -0800 (PST) Received: by 10.216.199.6 with HTTP; Wed, 5 Mar 2014 16:59:05 -0800 (PST) In-Reply-To: References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.com> Date: Wed, 5 Mar 2014 18:59:05 -0600 Message-ID: From: Nico Williams To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mH-rJus-v3JqRrycoWex2Q0kR8k Cc: Stephen Kent , "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 00:59:11 -0000 On Wed, Mar 5, 2014 at 6:35 PM, Bodo Moeller wrote: > I suppose if this becomes an actual concern for evaluation, you could create > a more easily evaluable module that accepts explicit IVs but checks that > these increase monotonically between invocations. (Accepting *explicit* IVs > doesn't mean you have to accept *arbitrary* IVs.) This. However in the DTLS case there's no way to make the sequence numbers be monotonic. What the module could do is keep its own IV sequence number window and reject the use of sequence numbers that are too old or reused... ...but note that in the decrypt case it may still be useful to know that a message is a replay and yet get the authentication tag state and plaintext outputs. The GSS-API's GSS_Unwrap() function supports this. Having a sequence number window in the algorithm module is a PITA, but much less a PITA than having to validate all of a TLS implementation. > (Implicitly, this would also enforce the TLS requirement that sequence > numbers are not allowed to wrap around once you're beyond 2^64 records.) And if the IV must initially be randomly chosen, let the module generate it but let the user (TLS) furnish the sequence numbers to add to the initial IV to get the actual IV. Of course, this does mean that on decrypt the algorithm module will have to output the sequence number/IV. So this is really an exercise in designing an API to the cipher+mode that allows the provider to be validated separately from the user application, and still provide desired assurances to the validator. Nico -- T From nobody Wed Mar 5 17:19:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F9E1A0007 for ; Wed, 5 Mar 2014 17:19:32 -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 LZKeWi7d0k4t for ; Wed, 5 Mar 2014 17:19:31 -0800 (PST) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id EB0641A0011 for ; Wed, 5 Mar 2014 17:19:30 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id rq2so1856632pbb.33 for ; Wed, 05 Mar 2014 17:19: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0b65O49I4xjWhtrMYPCEKGZjm488jO1XufH1C9vmykg=; b=FoicjC9pgk+P7PhtyDCdy7PG95ThJJvB+eyFM8coosWQQNjyS+5fVxigDamf9aBK8h PHrbEyalheHeHDXhrG63LJx5HwDAzwNT0gGKHgfFTh9Lhjx5dwtyFSUT39T5E7wUpJMD bpOI7CfyofqVZ0AKKwn+aqrFi8x5KKNqHIxPGpUFCKtWLYvnpTwSm4UMrAWlFyJ8zpJy f5P8Yr4VjUJ3Ebk3cK1R8n2DP2TVhGQxkTmyw0/DrblC7OelOkdOEQPhV2w9rjfgGIAe Vh7yGdjai81ZSIX54sPxMuMTr0kTFLFI6R2Vmez82rXDupeEj73C7icKvitglu1deFH5 wWRA== X-Gm-Message-State: ALoCoQkzfzB0B1Bm/rFgaOCy2bXQ3RTH4rCVrmZHIJj3t0yD52qUB7z7OqHolEZmk5iEAa84qY7M X-Received: by 10.68.215.68 with SMTP id og4mr10850706pbc.112.1394068767097; Wed, 05 Mar 2014 17:19:27 -0800 (PST) Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id un5sm25250887pab.3.2014.03.05.17.19.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 17:19:25 -0800 (PST) Message-ID: <5317CD1B.5010800@mit.edu> Date: Wed, 05 Mar 2014 17:19:23 -0800 From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nico Williams , Bodo Moeller References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eJE_aIc6hXFuSuPRtimMX_HWJM0 Cc: Stephen Kent , "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 01:19:33 -0000 On 03/05/2014 04:59 PM, Nico Williams wrote: > On Wed, Mar 5, 2014 at 6:35 PM, Bodo Moeller wrote: >> I suppose if this becomes an actual concern for evaluation, you could create >> a more easily evaluable module that accepts explicit IVs but checks that >> these increase monotonically between invocations. (Accepting *explicit* IVs >> doesn't mean you have to accept *arbitrary* IVs.) > > This. > > However in the DTLS case there's no way to make the sequence numbers > be monotonic. What the module could do is keep its own IV sequence > number window and reject the use of sequence numbers that are too old > or reused... DTLS is fine with strictly monotonic *encryption* sequence numbers, right? And I don't think it's a problem if an AEAD is asked to *decrypt* repeated sequence numbers. (It's certainly a problem if an attacker can access the decryption of two different messages with the same sequence if they don't both verify, but this is solvable by having the crypto implementation refuse to supply the supposed plaintext if the tag is bad.) --Andy From nobody Wed Mar 5 17:27:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68BD1A0011 for ; Wed, 5 Mar 2014 17:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] 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 hYDi8hBM_zAZ for ; Wed, 5 Mar 2014 17:27:36 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (unknown [69.163.253.166]) by ietfa.amsl.com (Postfix) with ESMTP id E996E1A000A for ; Wed, 5 Mar 2014 17:27:36 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id CDDF477806E for ; Wed, 5 Mar 2014 17:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=DkIB39spswYHPhlere1E UhvMOSY=; b=N1Qxpg30JfHPIWY/KBbmbI4clGCAZDGpm6MVbuNZEBAu6L0ekp09 n3QuToui9BR5UOTnRn6UFzG0BohbZAk/Osx7o63QiGp/mx5Rct1rVO5oaGluOuVr KEAIcmH3oZtp9EPMYURfOzR2QKlIM4fQeRAH3dyg3LmG5tv71zk3vhs= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 8087D77805F for ; Wed, 5 Mar 2014 17:27:32 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id u57so2222314wes.36 for ; Wed, 05 Mar 2014 17:27:31 -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=7CFnKS3rUNSIqJa6V1lCTP9nVLTY5ecEJ9/JegC1fW4=; b=ZJ1+4t03VK3gbnK/27Z7vJ0llH2TGoC8SRscFQxRQgdc9YLZ6FhNTWJMuDb7+6V38C Xrm2uUf5D9F5oiSlrjl4odVYy7jGam999OLmsXNWhjcAKFUOdCsEeIr6bVe9xf/YKHet VsIc+b3pPH0jCGkNBpLYpxoXFGFQxIp1BJKeBqSe+qABH3I/vKK0PuOOT/WveV4NLvvD IoxfDfuFSiilJD4Jvir0WiHBzK8nqCIMMwLMZPJFilpRboC8UlZ7eUkzQgOUnFcX9cvL 8Lj9ik6hCrETaqOfdg47xQApy7MKopZtz33afTMJJ29u4ghTsJYSnZuhxWB2h+5A90Al k5BA== MIME-Version: 1.0 X-Received: by 10.194.204.199 with SMTP id la7mr1840987wjc.4.1394069251196; Wed, 05 Mar 2014 17:27:31 -0800 (PST) Received: by 10.216.199.6 with HTTP; Wed, 5 Mar 2014 17:27:31 -0800 (PST) In-Reply-To: <5317CD1B.5010800@mit.edu> References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.com> <5317CD1B.5010800@mit.edu> Date: Wed, 5 Mar 2014 19:27:31 -0600 Message-ID: From: Nico Williams To: Andy Lutomirski Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ga7dkSTnmUBVRkM-V8bnnHIRiJc Cc: Stephen Kent , "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 01:27:38 -0000 On Wed, Mar 5, 2014 at 7:19 PM, Andy Lutomirski wrote: > On 03/05/2014 04:59 PM, Nico Williams wrote: >> However in the DTLS case there's no way to make the sequence numbers >> be monotonic. What the module could do is keep its own IV sequence >> number window and reject the use of sequence numbers that are too old >> or reused... > > DTLS is fine with strictly monotonic *encryption* sequence numbers, > right? And I don't think it's a problem if an AEAD is asked to But DTLS is intended to be used with transports that do not guarantee in-order delivery, so on the receive side at least there's a need to permit out-of-order sequence numbers. On the send side too, for concurrency reasons, there's a need to permit out-of-order generation. (N threads sharing a DTLS connection, each using an atomic increment operation to get the next sequence number, then proceeding at their own pace do to the rest.) > *decrypt* repeated sequence numbers. [...] As long as the app gets the sequence number out so it can check for replays... Nico -- From nobody Wed Mar 5 17:37:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C281A0037 for ; Wed, 5 Mar 2014 17:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 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.547, 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 4LOF4Byjb61P for ; Wed, 5 Mar 2014 17:37:54 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 235821A0031 for ; Wed, 5 Mar 2014 17:37:53 -0800 (PST) Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0LcPxe-1X1cok2UHW-00jpG3; Thu, 06 Mar 2014 02:37:48 +0100 Received: by mail-yk0-f169.google.com with SMTP id 142so5002917ykq.0 for ; Wed, 05 Mar 2014 17:37:47 -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=5lIm0hfw0ROA4Ga6TUcHAwy+YsaOCGnrO/ye/FzbX3o=; b=VMVgrVQrTEuYudC07XFK2R/cVt/tkCxQIVKWa9gjyoaT1ZKzf0i6YKn1NWFvk+7TdM meGmqA6tRUHBjC6RgNDM14qICqre4D6vIYKHKxKJ74Z6ibblF31mZ9PGYTHU7+kinSji PukEKd0PtTAiScZh3V4HOzSIhIYlW/DkXiN4CS3GHclIiazR7LYGEwfcqt+8eRI6Wxro ih2ATciBughwW0vDXMm5Xw2gG1nklN4R+zQFrcZKsBAbDUAN0dsV3dpWE2Kk/xRsJwbx 5EXNJ1o+cldjkSWEYMpNCwWOMfh6fXe3pFj8r5zm5H+7X2te1/z78O2FrhvfUdhXRKxB cM0w== MIME-Version: 1.0 X-Received: by 10.236.47.162 with SMTP id t22mr450572yhb.123.1394069867564; Wed, 05 Mar 2014 17:37:47 -0800 (PST) Received: by 10.170.78.5 with HTTP; Wed, 5 Mar 2014 17:37:47 -0800 (PST) In-Reply-To: References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.com> Date: Wed, 5 Mar 2014 17:37:47 -0800 Message-ID: From: Bodo Moeller To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c1ec5c3f958e04f3e62fcd X-Provags-ID: V02:K0:OJjypjzIYEjwjtZWe6+C4gAk9nIyD95xf0LHwNgkOVj wumiQ87pmeXXuc/YeOGCLVIg2bxp8w2+jDF3addBKr3amIQp5+ c/vbpFe+V1Hl4+Pn/FpNyHv7hWc4Dv+sb+JeBmuFe/hB/O9eUj BD/BuH0UHKL1ZOteiV4Tsge476qvttLf3W3AtzZFosrN/tUFm5 ZQjMNX1v8JYwpUNRLO58xB7L6WqDy8zHCKNCqXbEZkjxC/lYcQ KwpvSEl4jF1Der0L83SLp4x36x3X44Byi9oQq/Wqlr62dS1Cl9 k/yEkpCJHXuhgK/T7IiNj2UeD56TtZU4C7e8bfgyPmSBWry6ki GWSGhlJjJdIvvesVG8kY7cWAFiRjz8ejaaB3piA3CM6PnHZxFC yYfqugK05/P3wlWJ1XMiJebysiScbqFaA+7giPpFJBvdVgiign 0qqed Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0OI4A3SX6R_yN_7cA5_qnVxXx-I Cc: Stephen Kent , "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 01:37:55 -0000 --001a11c1ec5c3f958e04f3e62fcd Content-Type: text/plain; charset=ISO-8859-1 Nico Williams : > On Wed, Mar 5, 2014 at 6:35 PM, Bodo Moeller wrote: > > > I suppose if this becomes an actual concern for evaluation, you could > create > > a more easily evaluable module that accepts explicit IVs but checks that > > these increase monotonically between invocations. (Accepting *explicit* > IVs > > doesn't mean you have to accept *arbitrary* IVs.) > > This. > > However in the DTLS case there's no way to make the sequence numbers > be monotonic. What the module could do is keep its own IV sequence > number window and reject the use of sequence numbers that are too old > or reused... > > ...but note that in the decrypt case it may still be useful to know > that a message is a replay and yet get the authentication tag state > and plaintext outputs. The GSS-API's GSS_Unwrap() function supports > this. > Right -- sorry, when I wrote the above, I only meant a check when *en*crypting. *De*cryption is normally expected to have to handle potentially arbitrary explicit IVs, anyway: for example, if encryption uses random IVs, decryption will just have to accept these -- you wouldn't be generating random IVs in the decryption module too :-). Bodo --001a11c1ec5c3f958e04f3e62fcd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Nico= Williams <nico@cryptonector.com>:
On Wed, Mar 5, 2014 at 6:35 = PM, Bodo Moeller <bmoeller@acm.org> wrote:
> I suppose if this becomes an actual concern for evaluation, you could = create
> a more easily evaluable module that accepts explicit IVs but checks th= at
> these increase monotonically between invocations. =A0(Accepting *expli= cit* IVs
> doesn't mean you have to accept *arbitrary* IVs.)

This.

However in the DTLS case there's no way to make the sequence numbers be monotonic. =A0What the module could do is keep its own IV sequence
number window and reject the use of sequence numbers that are too old
or reused...

...but note that in the decrypt case it may still be useful to know
that a message is a replay and yet get the authentication tag state
and plaintext outputs. =A0The GSS-API's GSS_Unwrap() function supports<= br> this.


Bodo

--001a11c1ec5c3f958e04f3e62fcd-- From nobody Wed Mar 5 17:41:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E435E1A0037 for ; Wed, 5 Mar 2014 17:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 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.547, 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 oF-c0fmfLzLA for ; Wed, 5 Mar 2014 17:41:48 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id BFC541A0031 for ; Wed, 5 Mar 2014 17:41:47 -0800 (PST) Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0M7EPO-1X5tvE42GE-00wzMO; Thu, 06 Mar 2014 02:41:43 +0100 Received: by mail-yh0-f47.google.com with SMTP id c41so1994348yho.20 for ; Wed, 05 Mar 2014 17:41: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=sJI3EKBFsabs9u/mVrPVIwL8gj4CoCqIYr+JmWh2Lfk=; b=EsNQ0WRY7a50WzmfNolsait3ZuZ/aQri2mxtnP4Eg9eLTAFnIPuNx5DL+OeWjcvsoK +peVpF7xcmJQdgvJzps+UrM/kJ+ae9s3BaGKRFET6Gi0uhVvCPqbrgXdYosidUXfb5+V OaezJ7feLkzqgBCd/gw3NUSm0Kxz2FxPK6rn1+mp6niiBTnZAOoxNzcPEHtKDG5bFqPs 7pHwUr3hR/+bM3i2YNpFOwqgZ6O2rQvyL6LeNyqXwtkLduPPGNATzm/hNOS/9vAUZcPS 9SsdfoLmYXDvRtrMGdHyL8Kf6sbSV2SJovYdYi7LLv2iVCLd/0ZtSC6ef4ha+nZOmttB H5Gg== MIME-Version: 1.0 X-Received: by 10.236.199.82 with SMTP id w58mr10893502yhn.57.1394070101999; Wed, 05 Mar 2014 17:41:41 -0800 (PST) Received: by 10.170.78.5 with HTTP; Wed, 5 Mar 2014 17:41:41 -0800 (PST) In-Reply-To: References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.com> Date: Wed, 5 Mar 2014 17:41:41 -0800 Message-ID: From: Bodo Moeller To: Nico Williams Content-Type: multipart/alternative; boundary=089e0160b8f038c80204f3e63da0 X-Provags-ID: V02:K0:KVhCps021wEewYRiIiM4/MimmOUou4EAcFaTGCg2P8t xyBbWuAaO/pqbEpXldBlf4kleimN6NXsn2wacIdNQApEtd+May BnvkVW8jjdjbkxqiZsQBENpXmNFNwYHM8QsQ3Z+5ecBB9z3oE7 r4nQ0qIISo0X+AyDoZyL84kOcnGEUAKwypHlkt4XMZ9Pa2TkJd 4lf6NTWxTtwmFIGn+gFaE/+0R5XHILcPqswG/jYZyVaI2xxx97 9WRWSduNIcuw3zifPpc8tAiyiPE/FFhYR5+hhT5tJSlGXE9OMo PvqRXkhRzRfx86ZBqCPlsszBSJjz1kGyuSeOjdY4aYWK6h5O+Q PvkDfYbIkbKtVEkDzl/5cL1eR25BFlfxYy5KtLajOweaaMzPpj SWDeXCiwUm9CoHf5xQonEonhmwyvRJxhu2pmfgJaHT6oQamF1X DEsdJ Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oJ3tOSswow8uXHg-hDnXPqLD4ro Cc: Stephen Kent , "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 01:41:49 -0000 --089e0160b8f038c80204f3e63da0 Content-Type: text/plain; charset=ISO-8859-1 Bodo Moeller : Right -- sorry, when I wrote the above, I only meant a check when > *en*crypting. > (And accordingly, IVs *can* be monotic even with DTLS, as Andy has already pointed out. This isn't a property that the receiver can check, but if we were to add explicit random IVs in addition to the explicit DTLS sequence number, that clearly wouldn't provide anything for the receiver to check either.) --089e0160b8f038c80204f3e63da0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Bodo= Moeller <bmoeller@acm.org>:

Right -- sorry, when I wrote the above, I only meant a check when *en*cryp= ting.

(And accordin= gly, IVs *can* be monotic even with DTLS, as Andy has already pointed out. = =A0This isn't a property that the receiver can check, but if we were to= add explicit random IVs in addition to the explicit DTLS sequence number, = that clearly wouldn't provide anything for the receiver to check either= .)

--089e0160b8f038c80204f3e63da0-- From nobody Wed Mar 5 17:48:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714591A005A for ; Wed, 5 Mar 2014 17:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] 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 3tXJFRfN5Zg7 for ; Wed, 5 Mar 2014 17:48:15 -0800 (PST) Received: from homiemail-a54.g.dreamhost.com (unknown [69.163.253.168]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0E01A0057 for ; Wed, 5 Mar 2014 17:48:15 -0800 (PST) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 0B32C40122422 for ; Wed, 5 Mar 2014 17:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=fIZeXcPv3yG1By1UNRgh O0tYF3I=; b=x7rD93YdONUFcG6Pc8RXSf+HtBJMdoixN6je1ORUPf2g2PvvGTul +8l9/OC5fZ0uJAWv0TMBpZTIABf6GbzA3PgNKEaxaXSr6D8xZpjtaaV+zpFcn3cz RnRd8BeFfdNBnjc+5MbKRl76TlPPqla3v4FOAiErAC1INc0PRHKvAkk= Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id B00854012241C for ; Wed, 5 Mar 2014 17:48:11 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id w61so2252890wes.32 for ; Wed, 05 Mar 2014 17:48:10 -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=mRGvCaqyl+rErrFkkoKv6ITGf/gobOGWmCLiECqXKmA=; b=G3OOmaUobOriS4jdfiBPesEPOu/kNYdVuR39ktjP+Tv6eLGwlpGylmDWZuxy5Cmo2V Y61RbdBwqhNoErSPphoeKcWjAu11T0MOt1xrrjhiY+EFwiB7gV0RrFxFblGVwsCB1gie qODupUS1BnM3bxL99ibbkBJ528WjBX/FCI0bRHH2zKK8FKOC0n1ZdiviVdzkoo4XVPjT TjO9IRoSW/Pxtni/M8sLtGunwRWcJb1RuLh+3i7z+qiFkQwx/D/5h5Tpm5ZdvhleSTDH o5qtkK7/kW32FCvqV3Qdr4BugPHgEdWQjQgUD8vVY72R0bzCCD6tHplfqcKiaj+4GZWz Bg7w== MIME-Version: 1.0 X-Received: by 10.194.175.202 with SMTP id cc10mr5845661wjc.48.1394070490694; Wed, 05 Mar 2014 17:48:10 -0800 (PST) Received: by 10.216.199.6 with HTTP; Wed, 5 Mar 2014 17:48:10 -0800 (PST) In-Reply-To: References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.com> Date: Wed, 5 Mar 2014 19:48:10 -0600 Message-ID: From: Nico Williams To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ibqg8i3OcX48d9hHIkJ9D0UENS4 Cc: Stephen Kent , "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 01:48:16 -0000 On Wed, Mar 5, 2014 at 7:37 PM, Bodo Moeller wrote: > Right -- sorry, when I wrote the above, I only meant a check when > *en*crypting. *De*cryption is normally expected to have to handle > potentially arbitrary explicit IVs, anyway: for example, if encryption uses > random IVs, decryption will just have to accept these -- you wouldn't be > generating random IVs in the decryption module too :-). Again, the module might check a sequence number window of its own. And on the encryption side you should want a threaded program to be able to encrypt out of order. DTLS' out of order functionality is not (or need not be) just in case the transport reorders. Nico -- From nobody Wed Mar 5 18:04:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A41F1A0056 for ; Wed, 5 Mar 2014 18:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2ubVe7cMs9N for ; Wed, 5 Mar 2014 18:04:46 -0800 (PST) Received: from claranet-outbound-smtp09.uk.clara.net (claranet-outbound-smtp09.uk.clara.net [195.8.89.42]) by ietfa.amsl.com (Postfix) with ESMTP id B3CFE1A0060 for ; Wed, 5 Mar 2014 18:04:44 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:23031 helo=[192.168.7.9]) by relay19.mail.eu.clara.net (relay.clara.net [81.171.239.39]:10465) with esmtpa (authdaemon_plain:drh) id 1WLNfo-0007YY-Tv for tls@ietf.org (return-path ); Thu, 06 Mar 2014 02:04:36 +0000 Message-ID: <5317D7AF.60400@drh-consultancy.co.uk> Date: Thu, 06 Mar 2014 02:04:31 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iOhFfN2h7TyqSTpmQF5m4Fdxy_E Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 02:04:50 -0000 On 06/03/2014 01:37, Bodo Moeller wrote: > > Right -- sorry, when I wrote the above, I only meant a check when *en*crypting. > *De*cryption is normally expected to have to handle potentially arbitrary > explicit IVs, anyway: for example, if encryption uses random IVs, decryption > will just have to accept these -- you wouldn't be generating random IVs in the > decryption module too :-). > I can confirm that and I did specifically ask about it: there are no "generated internally in the module" IV requirements for decryption it can be explicitly stated in an API call. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nobody Wed Mar 5 18:33:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9F51A0081 for ; Wed, 5 Mar 2014 18:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 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.547, 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 2c7vq5p6TiL9 for ; Wed, 5 Mar 2014 18:33:54 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5E49B1A0056 for ; Wed, 5 Mar 2014 18:33:54 -0800 (PST) Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0MN4u0-1WJA8q4AGm-006hfi; Thu, 06 Mar 2014 03:33:49 +0100 Received: by mail-yh0-f47.google.com with SMTP id c41so2039390yho.20 for ; Wed, 05 Mar 2014 18:33:48 -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=Q0C2XMvQ5oOHJowGvv3Ax+uX73v9qVhrwmnlU7F6EVI=; b=MIJEv5nhdeixjqe83RmX7oDgOzw7GNaOiZxul6wfUSfSjvh2eX8iPZ1DpZDrmaDaRH jHUFYRSW9VxIZo753/I2gkCPYsx7us/fLL2lqRiw8uTTU/dyXzLMeuHl91kUEVyIUdnI cfdYIDekTqtOmZuYbVRRAjpjY711oKome14XLN/MhxDH0mjq7CFLiNuWMWCnkTWUgkI/ 6qL230f3Myn+77Tx0gMDbDKaeoNrWKzkdkrda5t09l7JTxr5/19RQDfT52ylCpHqpvvN zGjV1gVb3snjg8hRGby/GW9OR4cbTTSyBSfn86s8KcvhP7iMVVYEUJ9CFYFVr2cOJhZd oYjA== MIME-Version: 1.0 X-Received: by 10.236.82.226 with SMTP id o62mr11348241yhe.90.1394073227981; Wed, 05 Mar 2014 18:33:47 -0800 (PST) Received: by 10.170.78.5 with HTTP; Wed, 5 Mar 2014 18:33:47 -0800 (PST) In-Reply-To: References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.com> Date: Wed, 5 Mar 2014 18:33:47 -0800 Message-ID: From: Bodo Moeller To: Nico Williams Content-Type: multipart/alternative; boundary=20cf3010e3ef8bc0c104f3e6f7be X-Provags-ID: V02:K0:8LyINNVsI6XHA6XPUgUc15JFB3iX/h5uwH4n+NZ2lAs dfrvdT74nvgbofexAd4Nd/bg3QXM/ZXofBbLG9g6ZOM9moaCm6 hXVjx9v4RqxwcbffyAQ9epDOtowHcZ3Mw8rq8yC+hSxNCm01js OT8lGWnW2FXUo8Hc3itWy7t2fjqEk/dJI3ljMSyB6FxPkz4fzl PyfdUGhSU9Vi0zBAN++OMAjkVtrfeYlggBtLmhrllG/oQLnNxj 9cAYkm9Shxa/JVlCQuSV5Lkp5srlLzQjpMuOzlo9khNcUCkFlQ 7LsngpWk/k07yoPAAVIut5/utJ6Og1HwHVnXGk2KvoCRTw2RQW EF7MgnqDHDJV0FVweHqcY83gdQRf1w8UeZM7p4O8N5ho1qCsA/ O8MAHJRi9EG5yVUwTxb+myoIPTs6WGUCImoRldM/l//eJ8ryyH RADXz Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MKvKS-IsbeNEyMnHs7PDAA0izbg Cc: Stephen Kent , "tls@ietf.org" Subject: Re: [TLS] ChaCha and IVs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 02:33:56 -0000 --20cf3010e3ef8bc0c104f3e6f7be Content-Type: text/plain; charset=ISO-8859-1 Nico Williams : > Bodo Moeller wrote: > > > Right -- sorry, when I wrote the above, I only meant a check when > > *en*crypting. *De*cryption is normally expected to have to handle > > potentially arbitrary explicit IVs, anyway: for example, if encryption > uses > > random IVs, decryption will just have to accept these -- you wouldn't be > > generating random IVs in the decryption module too :-). > > Again, the module might check a sequence number window of its own. > And on the encryption side you should want a threaded program to be > able to encrypt out of order. DTLS' out of order functionality is not > (or need not be) just in case the transport reorders. I do understand that, but we have three competing optimization goals here: - Keep the code requiring FIPS evaluation (if that's required) as small as possible. - Avoid the overhead of an explicit IV [as a side-effect, improving security -- a counter is better than random IVs]. - Allow optimal parallelization. Pick any two. For example, if you introduce random IVs to allow concurrent encryption by multiple threads in a more easily evaluable encryption module, while encryption can get faster, the explicit IV also means you end up with more data to send. It's not clear why that would be the best trade-off. Bodo --20cf3010e3ef8bc0c104f3e6f7be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Nico= Williams <nico@cryptonector.com>:
Bodo Moeller <bmoell= er@acm.org> wrote:
=A0
> Right -- sorry, when I wrote the above, I only meant a check when
> *en*crypting. *De*cryption is normally expected to have to handle
> potentially arbitrary explicit IVs, anyway: for example, if encryption= uses
> random IVs, decryption will just have to accept these -- you wouldn= 9;t be
> generating random IVs in the decryption module too :-).
=A0
Again, the module might check a sequence number window of its own. And on the encryption side you should want a threaded program to be
able to encrypt out of order. =A0DTLS' out of order functionality is no= t
(or need not be) just in case the transport reorders.

=
I do understand that, but we have three competing optimization g= oals here:

- Keep the code requiring FIPS evaluati= on (if that's required) as small as possible.
- Avoid the overhead of an explicit IV [as a side-effect, improving se= curity -- a counter is better than random IVs].
- Allow optimal p= arallelization.

Pick any two. =A0For example, if y= ou introduce random IVs to allow concurrent encryption by multiple threads = in a more easily evaluable encryption module, while encryption can get fast= er, the explicit IV also means you end up with more data to send. =A0It'= ;s not clear why that would be the best trade-off.

Bodo

--20cf3010e3ef8bc0c104f3e6f7be-- From nobody Thu Mar 6 08:56:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7A71A00BA for ; Thu, 6 Mar 2014 08:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 7YB0jOsvSVmb for ; Thu, 6 Mar 2014 08:56:12 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id DD4551A00A2 for ; Thu, 6 Mar 2014 08:56:11 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:55155 helo=dhcp-a3d7.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WLbaZ-0002l0-EN for tls@ietf.org; Thu, 06 Mar 2014 11:56:07 -0500 Message-ID: <5318A8A6.50201@bbn.com> Date: Thu, 06 Mar 2014 11:56:06 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: multipart/alternative; boundary="------------040200000006060507090507" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/580uTHKfLjJUB1zcGt_h80g2Ahw Subject: [TLS] where IVs come from (and other mysteries ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 16:56:19 -0000 This is a multi-part message in MIME format. --------------040200000006060507090507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, My message about IV generation certainly triggered a lot of responses. Some of these appear to result from the "I didn't read the slides" phenomenon. Some others appear to result from not understanding how the NIST Cryptography Module Validation Program (CMVP) operates and why. And then the discussion expanded well beyond the focus of my comments/slides. Only one response was a valid rebuttal to my assertion that the CMVP requires generation of a counter mode IV inside the evaluation boundary. That well-written message surprised me, and caused me to do some homework, the results of which are provided below. With regard to reading the slides: Slide 6 noted that ChaCha is not a FIPS approved algorithm, and thus is not eligible for CMVP evaluation. It also noted that some folks asked Tim Polk (NIST) if it might be evaluated, and Tim didn't say no. So, I observed that IF folks want ChaCha to be a viable candidate, THEN it makes sense to not propose using it in a way that runs counter to the evaluation criteria. Some folks believed that I was arguing that ChaCha needed to use pseudorandom IVs, generated within the cryptography module boundary. The slides do not say this. It would be fine to use a counter or a LFSR to generate a unique sequence of IVs for ChaCha. The requirement, I stated, was that this be performed within the evaluation (module) boundary. So, one might use a counter for IVs in a module, and yes, that might duplicate the sequence numbers already used by a protocol like TLS or ESP. This wastes space in each packet, but we already live with it in ESP and in other cryptography algorithm / mode combinations in DTLS. With regard to how CMVP evaluation works: Arguments that TLS/DTLS (orESP) won't work if the sequence number it generates is managed correctly, and thus they are guarantee to be unique, are generally irrelevant to such evaluation. The evaluation of an algorithm / mode is with respect to the declared boundary for the module being evaluated. Now, with respect to the one message that really caught my attention. Wan-The Chang noted that a number of evaluated modules carry an indication that they make use of externally generated IVs with AES GCM. He provided very precise references in his well written, even handed message. I was surprizsd by what I found, so I checked with NIST and received the following response: ..., these are saying external to the "algorithm" not "external to the "module". I agree that the information is confusing and misleading and would work with CMVP and CAVP to clarify the statement. So, in fact, the evaluations are being performed as specified by the relevant NIST documents, from which I quite below: AES-CGM is defined in NIST 800-38D. Section 8 of this document discusses IV construction, with both deterministic and RBG-based approaches. Section 9 is entitled "Practical Considerations for Validating Implementations*"*and it**notes (red highlighting is mine): */9.1 Design Considerations /* In order to inhibit an unauthorized party from controlling or influencing the generation of IVs, GCM shall be implemented only within a cryptographic module that meets the requirements of FIPS Pub. 140-2. *In particular, the cryptographic boundary of the module shall contain a "generation unit" that produces IVs according to one of the constructions in Sec. 8.2 above. * This text clearly states that, for this algorithm and mode, the IV needs to be generated within the evaluated cryptography module boundary. So, what went wrong? I don't know, but I did find a very recent NITS publication: Implementation Guidance for FIPS 140-2 and the Cryptographic Module Validation program (1/17/2014).Documents providing guidance to folks performing module validation are issued periodically, e.g., to resolve areas where there has been ambiguity, confusion, etc. In this document the relevant text is in Section A.5, which discusses Key/IV pair Uniqueness requirements from SP 800-38D (the document quoted above). It states: One difficulty of testing the modules compliance with this requirement comes from the fact that each module is tested independently while *SP 800-38D *demands that the probability of the (Key, IV) pair collision between all modules at all times should be sufficiently low to ensure cryptographic strength. *Question/Problem * How shall a cryptographic module satisfy the requirements of Section 8 of *SP 800-38D? * *Resolution * There are several scenarios that may take place. First, the AES GCM key may be generated internally in a cryptographic module. Second, the key can be entered into the module. The IV is generated internally, according to Section 9.1 of *SP 800-38D. *It may be either generated randomly or set deterministically, possibly by being incremented by 1 every time a new value is needed. Here is the summary of the requirements that the cryptographic module *shall *satisfy. *1.**The external generation of the IVs is not allowed. * There are more details in A.5, but the first one applies irrespective of the latter ones. This rather strong statement is clear, and consistent with the highlighted text from 800-38D, noted above. The bottom line is that, contrary to what one might infer from the terminology used in the certificates, all IVs for use with AES GCM are generated within the evaluation (module) boundary, as called for in the standards cited above. That leaves just David McGrew's comments with respect to supplying an IV externally, and having a module verify that it was correct. I'll chat with David about this, to get a better sense of what he was thinking. But, as far as CMVP is concerned, this does not appear to be an op --------------040200000006060507090507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Folks,


My message about IV generation certainly triggered a lot of responses. Some of these appear to result from the “I didn’t read the slides” phenomenon. Some others appear to result from not understanding how the NIST Cryptography Module Validation Program (CMVP) operates and why. And then the discussion expanded well beyond the focus of my comments/slides. Only one response was a valid rebuttal to my assertion that the CMVP requires generation of a counter mode IV inside the evaluation boundary. That well-written message surprised me, and caused me to do some homework, the results of which are provided below.

 

With regard to reading the slides:


            Slide 6 noted that ChaCha is not a FIPS approved algorithm, and thus is not eligible for CMVP evaluation. It also noted that some folks asked Tim Polk (NIST) if it might be evaluated, and Tim didn’t say no. So, I observed that IF folks want ChaCha to be a viable candidate, THEN it makes sense to not propose using it in a way that runs counter to the evaluation criteria.

 

            Some folks believed that I was arguing that ChaCha needed to use pseudorandom IVs, generated within the cryptography module boundary. The slides do not say this. It would be fine to use a counter or a LFSR to generate a unique sequence of IVs for ChaCha. The requirement, I stated, was that this be performed within the evaluation (module) boundary. So, one might use a counter for IVs in a module, and yes, that might duplicate the sequence numbers already used by a protocol like TLS or ESP. This wastes space in each packet, but we already live with it in ESP and in other cryptography algorithm / mode combinations in DTLS.

 

With regard to how CMVP evaluation works:


            Arguments that TLS/DTLS (or  ESP) won’t work if the sequence number it generates is managed correctly, and thus they are guarantee to be unique, are generally irrelevant to such evaluation. The evaluation of an algorithm / mode is with respect to the declared boundary for the module being evaluated.

 

Now, with respect to the one message that really caught my attention. Wan-The Chang noted that a number of evaluated modules carry an indication that they make use of externally generated IVs with AES GCM. He provided very precise references in his well written, even handed message. I was surprizsd by what I found, so  I checked with NIST  and received the following response:

 

…, these are saying external to the “algorithm” not “external to the “module”.  I agree that the information is confusing and misleading and would work with CMVP and CAVP to clarify the statement. 

 

So, in fact, the evaluations are being performed as specified by the relevant NIST documents, from which I quite below:

 

AES-CGM is defined in NIST 800-38D. Section 8 of this document discusses IV construction, with both deterministic and RBG-based approaches. Section 9 is entitled “Practical Considerations for Validating Implementations”  and it notes (red highlighting is mine):

9.1 Design Considerations

In order to inhibit an unauthorized party from controlling or influencing the generation of IVs, GCM shall be implemented only within a cryptographic module that meets the requirements of FIPS Pub. 140-2. In particular, the cryptographic boundary of the module shall contain a “generation unit” that produces IVs according to one of the constructions in Sec. 8.2 above.

This text clearly states that, for this algorithm and mode, the IV needs to be generated within the evaluated cryptography module boundary. So, what went wrong? I don’t know, but I did find a very recent NITS publication: Implementation Guidance for FIPS 140-2 and the Cryptographic Module Validation program (1/17/2014).  Documents providing guidance to folks performing module validation are issued periodically, e.g., to resolve areas where there has been ambiguity, confusion, etc. In this document the relevant text is in Section A.5, which discusses Key/IV pair Uniqueness requirements from SP 800-38D (the document quoted above). It states:

One difficulty of testing the modules compliance with this requirement comes from the fact that each module is tested independently while SP 800-38D demands that the probability of the (Key, IV) pair collision between all modules at all times should be sufficiently low to ensure cryptographic strength.

Question/Problem

How shall a cryptographic module satisfy the requirements of Section 8 of SP 800-38D?

Resolution

There are several scenarios that may take place. First, the AES GCM key may be generated internally in a cryptographic module. Second, the key can be entered into the module.

The IV is generated internally, according to Section 9.1 of SP 800-38D. It may be either generated randomly or set deterministically, possibly by being incremented by 1 every time a new value is needed.

Here is the summary of the requirements that the cryptographic module shall satisfy.

1.     The external generation of the IVs is not allowed.

There are more details in A.5, but the first one applies irrespective of the latter ones. This rather strong statement is clear, and consistent with the highlighted text from 800-38D, noted above.

The bottom line is that, contrary to what one might infer from the terminology used in the certificates, all IVs for use with AES GCM are generated within the evaluation (module) boundary, as called for in the standards cited above.

That leaves just David McGrew’s comments with respect to supplying an IV externally, and having a module verify that it was correct. I’ll chat with David about this, to get a better sense of what he was thinking. But, as far as CMVP is concerned, this does not appear to be an op --------------040200000006060507090507-- From nobody Thu Mar 6 09:19:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CBE1A02A9 for ; Thu, 6 Mar 2014 09:19: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 tfgD_tHXTMIE for ; Thu, 6 Mar 2014 09:19:03 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id 807031A029E for ; Thu, 6 Mar 2014 09:19:03 -0800 (PST) Received: by mail-yk0-f176.google.com with SMTP id 19so7442241ykq.7 for ; Thu, 06 Mar 2014 09:18:59 -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=Uo3e+tc8xlB3HF5UMx3Cbzo+e/o/+kATpM90EaoRRNc=; b=wmm8BAx3jb9NWFyELU39kZZ7Tlw5S4yhmG99IUGGJcip52UFqQL/4EyrI/DwudMXh8 CzgbNxSPdqYxyQPUi4Jn1npI50g999bmQKbOxr3fnVQHaYspBt2tKqJ26SVGyJbfYo78 8zL+VnYErNVJNVIx183b+c/M5rE/kb6M2B33VDliWRsCjdR0El+s9A6z2IaB2/tUBknS XcKpI1CaAzFB6mJ2jAcN07vK/fL+SovdDQNxpp3O7usG7zElQu+EYaRFtDthSroGHZXC nHTf9MIFFGkb/5SsX7cIiqulg/N+m2O4OmiOR1nObdm2mINpxLG2gPcjc7eYFxgod4h3 7BSg== MIME-Version: 1.0 X-Received: by 10.236.198.197 with SMTP id v45mr14514643yhn.87.1394126339408; Thu, 06 Mar 2014 09:18:59 -0800 (PST) Received: by 10.170.92.85 with HTTP; Thu, 6 Mar 2014 09:18:59 -0800 (PST) In-Reply-To: <5318A8A6.50201@bbn.com> References: <5318A8A6.50201@bbn.com> Date: Thu, 6 Mar 2014 09:18:59 -0800 Message-ID: From: Watson Ladd To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SXFoI7GfqEI0NkeNuaxmfqJ1qRc Cc: "tls@ietf.org" Subject: Re: [TLS] where IVs come from (and other mysteries ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 17:19:06 -0000 What is the value of evaluation if it does not include the entire TLS stack? The bugs are not living in the core crypto modules which are easily tested: they live at a higher level. Secondly, I don't see why a module that uses a counter as an IV cannot output it in the right place to be a TLS sequence number. Yes, this restricts the module design, but it doesn't prevent compliance with the NIST requirements. Sincerely, Watson Ladd On Thu, Mar 6, 2014 at 8:56 AM, Stephen Kent wrote: > Folks, > > > My message about IV generation certainly triggered a lot of responses. So= me > of these appear to result from the =E2=80=9CI didn=E2=80=99t read the sli= des=E2=80=9D phenomenon. > Some others appear to result from not understanding how the NIST > Cryptography Module Validation Program (CMVP) operates and why. And then = the > discussion expanded well beyond the focus of my comments/slides. Only one > response was a valid rebuttal to my assertion that the CMVP requires > generation of a counter mode IV inside the evaluation boundary. That > well-written message surprised me, and caused me to do some homework, the > results of which are provided below. > > > > With regard to reading the slides: > > > Slide 6 noted that ChaCha is not a FIPS approved algorithm, a= nd > thus is not eligible for CMVP evaluation. It also noted that some folks > asked Tim Polk (NIST) if it might be evaluated, and Tim didn=E2=80=99t sa= y no. So, I > observed that IF folks want ChaCha to be a viable candidate, THEN it make= s > sense to not propose using it in a way that runs counter to the evaluatio= n > criteria. > > > > Some folks believed that I was arguing that ChaCha needed to = use > pseudorandom IVs, generated within the cryptography module boundary. The > slides do not say this. It would be fine to use a counter or a LFSR to > generate a unique sequence of IVs for ChaCha. The requirement, I stated, = was > that this be performed within the evaluation (module) boundary. So, one > might use a counter for IVs in a module, and yes, that might duplicate th= e > sequence numbers already used by a protocol like TLS or ESP. This wastes > space in each packet, but we already live with it in ESP and in other > cryptography algorithm / mode combinations in DTLS. > > > > With regard to how CMVP evaluation works: > > > Arguments that TLS/DTLS (or ESP) won=E2=80=99t work if the s= equence > number it generates is managed correctly, and thus they are guarantee to = be > unique, are generally irrelevant to such evaluation. The evaluation of an > algorithm / mode is with respect to the declared boundary for the module > being evaluated. > > > > Now, with respect to the one message that really caught my attention. > Wan-The Chang noted that a number of evaluated modules carry an indicatio= n > that they make use of externally generated IVs with AES GCM. He provided > very precise references in his well written, even handed message. I was > surprizsd by what I found, so I checked with NIST and received the > following response: > > > > =E2=80=A6, these are saying external to the =E2=80=9Calgorithm=E2=80=9D n= ot =E2=80=9Cexternal to the > =E2=80=9Cmodule=E2=80=9D. I agree that the information is confusing and = misleading and > would work with CMVP and CAVP to clarify the statement. > > > > So, in fact, the evaluations are being performed as specified by the > relevant NIST documents, from which I quite below: > > > > AES-CGM is defined in NIST 800-38D. Section 8 of this document discusses = IV > construction, with both deterministic and RBG-based approaches. Section 9= is > entitled =E2=80=9CPractical Considerations for Validating Implementations= =E2=80=9D and it > notes (red highlighting is mine): > > 9.1 Design Considerations > > In order to inhibit an unauthorized party from controlling or influencing > the generation of IVs, GCM shall be implemented only within a cryptograph= ic > module that meets the requirements of FIPS Pub. 140-2. In particular, the > cryptographic boundary of the module shall contain a =E2=80=9Cgeneration = unit=E2=80=9D that > produces IVs according to one of the constructions in Sec. 8.2 above. > > This text clearly states that, for this algorithm and mode, the IV needs = to > be generated within the evaluated cryptography module boundary. So, what > went wrong? I don=E2=80=99t know, but I did find a very recent NITS publi= cation: > Implementation Guidance for FIPS 140-2 and the Cryptographic Module > Validation program (1/17/2014). Documents providing guidance to folks > performing module validation are issued periodically, e.g., to resolve ar= eas > where there has been ambiguity, confusion, etc. In this document the > relevant text is in Section A.5, which discusses Key/IV pair Uniqueness > requirements from SP 800-38D (the document quoted above). It states: > > One difficulty of testing the modules compliance with this requirement co= mes > from the fact that each module is tested independently while SP 800-38D > demands that the probability of the (Key, IV) pair collision between all > modules at all times should be sufficiently low to ensure cryptographic > strength. > > Question/Problem > > How shall a cryptographic module satisfy the requirements of Section 8 of= SP > 800-38D? > > Resolution > > There are several scenarios that may take place. First, the AES GCM key m= ay > be generated internally in a cryptographic module. Second, the key can be > entered into the module. > > The IV is generated internally, according to Section 9.1 of SP 800-38D. I= t > may be either generated randomly or set deterministically, possibly by be= ing > incremented by 1 every time a new value is needed. > > Here is the summary of the requirements that the cryptographic module sha= ll > satisfy. > > 1. The external generation of the IVs is not allowed. > > There are more details in A.5, but the first one applies irrespective of = the > latter ones. This rather strong statement is clear, and consistent with t= he > highlighted text from 800-38D, noted above. > > The bottom line is that, contrary to what one might infer from the > terminology used in the certificates, all IVs for use with AES GCM are > generated within the evaluation (module) boundary, as called for in the > standards cited above. > > That leaves just David McGrew=E2=80=99s comments with respect to supplyin= g an IV > externally, and having a module verify that it was correct. I=E2=80=99ll = chat with > David about this, to get a better sense of what he was thinking. But, as = far > as CMVP is concerned, this does not appear to be an op > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Mar 6 09:21:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1350D1A01EB for ; Thu, 6 Mar 2014 09:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8k7fGcrlruq for ; Thu, 6 Mar 2014 09:20:55 -0800 (PST) Received: from claranet-outbound-smtp07.uk.clara.net (claranet-outbound-smtp07.uk.clara.net [195.8.89.40]) by ietfa.amsl.com (Postfix) with ESMTP id F1E5C1A02BD for ; Thu, 6 Mar 2014 09:20:54 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:48156 helo=[192.168.7.9]) by relay17.mail.eu.clara.net (relay.clara.net [81.171.239.37]:10465) with esmtpa (authdaemon_plain:drh) id 1WLbyR-0006cu-Od (return-path ); Thu, 06 Mar 2014 17:20:47 +0000 Message-ID: <5318AE6A.5060705@drh-consultancy.co.uk> Date: Thu, 06 Mar 2014 17:20:42 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , tls@ietf.org References: <5318A8A6.50201@bbn.com> In-Reply-To: <5318A8A6.50201@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k8y8B8iy5XDy6W4334vQXxkksks Subject: Re: [TLS] where IVs come from (and other mysteries ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 17:20:59 -0000 On 06/03/2014 16:56, Stephen Kent wrote: > > This text clearly states that, for this algorithm and mode, the IV needs to be > generated within the evaluated cryptography module boundary. So, what went > wrong? I dont know, but I did find a very recent NITS publication: > Implementation Guidance for FIPS 140-2 and the Cryptographic Module Validation > program (1/17/2014). [snip] > Here is the summary of the requirements that the cryptographic module *shall > *satisfy. > > *1. **The external generation of the IVs is not allowed. * > Although the date on that document is 2014 I have a copy of an earlier version of the document dating from March 3rd, 2011 which includes exactly the same statement. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nobody Thu Mar 6 09:35:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0242C1A0217 for ; Thu, 6 Mar 2014 09:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yot7rdpFbhGN for ; Thu, 6 Mar 2014 09:35:11 -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 DDFA01A014D for ; Thu, 6 Mar 2014 09:35:10 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9E81228501; Thu, 6 Mar 2014 17:35:06 +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 3B29D284FC; Thu, 6 Mar 2014 17:35:06 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 3231920A3; Thu, 6 Mar 2014 17:35:06 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.104]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Thu, 6 Mar 2014 12:35:05 -0500 From: "Salz, Rich" To: Watson Ladd Date: Thu, 6 Mar 2014 12:35:03 -0500 Thread-Topic: [TLS] where IVs come from (and other mysteries ...) Thread-Index: Ac85YDzmSzznmGSKQ8+fwVBpfPvuTQAAbFJg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AAB0B@USMBX1.msg.corp.akamai.com> References: <5318A8A6.50201@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tbrjkpW85aae6fuY_6s3A1VvCCA Cc: "tls@ietf.org" Subject: Re: [TLS] where IVs come from (and other mysteries ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 17:35:12 -0000 PiBXaGF0IGlzIHRoZSB2YWx1ZSBvZiBldmFsdWF0aW9uIGlmIGl0IGRvZXMgbm90IGluY2x1ZGUg dGhlIGVudGlyZSBUTFMgc3RhY2s/DQoNCllvdSBldmVyIGRvbmUgYW4gZXZhbHVhdGlvbj8gIEV2 ZXIgdHJ5IHRvIHNlbGwgdG8gYW4gZW50aXR5IHRoYXQgcmVxdWlyZWQgRklQUy1jZXJ0aWZpZWQg Y3J5cHRvPw0KDQo+IFRoZSBidWdzIGFyZSBub3QgbGl2aW5nIGluIHRoZSBjb3JlIGNyeXB0byBt b2R1bGVzIHdoaWNoIGFyZSBlYXNpbHkgdGVzdGVkOiB0aGV5IGxpdmUgYXQgYSBoaWdoZXIgbGV2 ZWwuDQoNCkNlcnRhaW5seSBtYW55IGVtYmFycmFzc2luZyBvbmVzIGRvLCB5ZXMuICBCdXQgdGhh dCBkb2Vzbid0IG1lYW4gdGhhdCB0aGVyZSdzIG5vdCBidXNpbmVzcyB2YWx1ZSBpbiBiZWluZyBh YmxlIHRvIGdldCBjZXJ0aWZpZWQgY3J5cHRvLiAgTm93IGl0IG1pZ2h0IG5vdCBiZSBzb21ldGhp bmcgeW91IGNhcmUgYWJvdXQsIGJ1dCB0aGVyZSBhcmUgZm9sa3Mgb24gdGhpcyBsaXN0IHdobyBk by4NCg0KQW5kIGV2YWx1YXRpb24gaXNuJ3QgYSBjb2RlIHJldmlldyBhbmQgd2lsbCBub3QgKG5l Y2Vzc2FyaWx5KSBmaW5kIGJ1Z3MuDQoJL3IkDQoNCi0tICANClByaW5jaXBhbCBTZWN1cml0eSBF bmdpbmVlcg0KQWthbWFpIFRlY2hub2xvZ3kNCkNhbWJyaWRnZSwgTUENCg0K From nobody Thu Mar 6 10:08:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D551A0088 for ; Thu, 6 Mar 2014 10:08: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 pFG0TPAjlM7e for ; Thu, 6 Mar 2014 10:08:41 -0800 (PST) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 64F151A005E for ; Thu, 6 Mar 2014 10:08:41 -0800 (PST) Received: by mail-yh0-f46.google.com with SMTP id b6so62153yha.33 for ; Thu, 06 Mar 2014 10:08: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=zdjCG+XUwuthaFpBfHlYlU6k1x2DNMVw27IkVCw3CTs=; b=hZBrgV40MDGSuXzkzQ29diUWT60mylgOVamkndkawV1p10e09kGj6AIlIMKGngJC2J jxX4kYJZJYevBxWyktMEb48v8FJRLtWrclCMTpBR78Rn+yI7mYsSw/Tv2fVXK95yVG+W CmHwnDrrfni+kEhB8k6A0HjDXaxuiGm0aaEZzNwB3sosXlx28zYsPz0fn8oWiuaym3Gr qDujcwLEuRFXiUjsmev7C14piai0BAh3+eGXG0Nt/OpffKPYGx6Sc1YeOA19mZX1Vb4R QnNOG33UDnwRdkgzb1QHyRlCBYBjFa1q7+hkPIOzGzRkhqUvXY1jqhnq1Ywu+YgiZfWe C6QQ== MIME-Version: 1.0 X-Received: by 10.236.7.84 with SMTP id 60mr4684760yho.107.1394129317240; Thu, 06 Mar 2014 10:08:37 -0800 (PST) Received: by 10.170.92.85 with HTTP; Thu, 6 Mar 2014 10:08:37 -0800 (PST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AAB0B@USMBX1.msg.corp.akamai.com> References: <5318A8A6.50201@bbn.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AAB0B@USMBX1.msg.corp.akamai.com> Date: Thu, 6 Mar 2014 10:08:37 -0800 Message-ID: From: Watson Ladd To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kVVtXMrMgYQEGqTHBQn7ErgGQXM Cc: "tls@ietf.org" Subject: Re: [TLS] where IVs come from (and other mysteries ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 18:08:43 -0000 On Thu, Mar 6, 2014 at 9:35 AM, Salz, Rich wrote: >> What is the value of evaluation if it does not include the entire TLS stack? > > You ever done an evaluation? Ever try to sell to an entity that required FIPS-certified crypto? So the value is that some customers want it? Okay, I appreciate that concern. But I don't see why meeting it increases confidence in the property we actually care about, namely correctness of the entire implementation. It's particularly a problem when the goal is rendering the certification meaningless by excluding as much as possible from the scope. Substance matters. > >> The bugs are not living in the core crypto modules which are easily tested: they live at a higher level. > > Certainly many embarrassing ones do, yes. But that doesn't mean that there's not business value in being able to get certified crypto. Now it might not be something you care about, but there are folks on this list who do. Sure, but I don't quite appreciate why the module can't generate the TLS sequence number itself. Is there some complicated interaction of specs that I'm neglecting? > > And evaluation isn't a code review and will not (necessarily) find bugs. So it's a little sticker saying "We did nothing to show this works. Have fun!"? Sincerely, Watson Ladd > /r$ > > -- > Principal Security Engineer > Akamai Technology > Cambridge, MA > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Mar 6 10:29:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B7D1A0265 for ; Thu, 6 Mar 2014 10:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 ZO0xDwurqxfP for ; Thu, 6 Mar 2014 10:29:29 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9711A0250 for ; Thu, 6 Mar 2014 10:29:18 -0800 (PST) Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0LyDKf-1XI4o13JFV-015b5r; Thu, 06 Mar 2014 19:29:13 +0100 Received: by mail-yk0-f177.google.com with SMTP id q200so7668762ykb.8 for ; Thu, 06 Mar 2014 10:29: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=9J7rm0HVFAbhLaCmj7r9C2P3cHRj8AjvO+5R4jlxbvs=; b=Cg8vYRhpwZMdbKts+YN2hFqux8i0gVJ8PUSXGbGQfHeZChge0v2HDtckevL/f9NB6J xCd4AAolwi8WvmeAse/DnzXyjT7FKFBO3RKkUr/0mXbYUE3XwWYhZdMQhF58rr6kQxVy lgcvrI+jKOBrwnwqNXpurDoZVn+bnwIwHKhEXXqAnOOL04MUarRp5wM6u8zV981K8i68 Zc5Dp8a+aBquFsstOaWEalYRbVMTvSvPoS7Ujp01fOQe7GhkRKF0VDg5T0hDpCjIdP65 mA1BMXiYEqm/v3t9D8LGWRLs1D+8CQQQT2rQe+czzWh3WuDuXOw20njEvGtMViYW9Bmp 1yvg== MIME-Version: 1.0 X-Received: by 10.236.75.74 with SMTP id y50mr16859111yhd.27.1394130551834; Thu, 06 Mar 2014 10:29:11 -0800 (PST) Received: by 10.170.78.5 with HTTP; Thu, 6 Mar 2014 10:29:11 -0800 (PST) In-Reply-To: References: <5318A8A6.50201@bbn.com> Date: Thu, 6 Mar 2014 10:29:11 -0800 Message-ID: From: Bodo Moeller To: Watson Ladd Content-Type: multipart/alternative; boundary=20cf3005137850167504f3f450ab X-Provags-ID: V02:K0:c9GGgGqldFrbeg7ItQ6K0YWt9Y2ABTaogT6uD5DTQ63 XSsFo3EMV7PHm2kdwhOJJ3s6xvh0SkfTw5VbOQfKxEI2WxLQpE Rw97l5n4RCKmiwQXb0rsHTlPtyoEoJM8IT1H9g5Z9RGUe+EF4g +ceYTs6TKYT2KWYQVq1CYluHIbtCRHM3f65ziLna3Wo0jqeAO8 PViFAOfR52n8DsssfWw6A5XEZ2gWAhnHbxF6aY+0S6+N8ei8C7 HSG+klInYLDJhK6DMj483vnj/Kv22jk/aSlJZ5OE42PzzOzc8X 6ZpZ1CJ5TolYv8JSwtdb1ETze8HovRlQr+1s1ulU8FD54vuUof os4mtji+Dm3BU5ljqsTmNLbBen4gXRiWEyzeCw5xYPIYLDZs3S O/ByyP8DQhNf7rmvoPJ7E4wCYZwqFOpP0E5fZmbzG45BJPdu3R IQ917 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rrG6B-RYTOmqORRSQ4qCSliW77I Cc: Stephen Kent , "tls@ietf.org" Subject: Re: [TLS] where IVs come from (and other mysteries ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 18:29:31 -0000 --20cf3005137850167504f3f450ab Content-Type: text/plain; charset=ISO-8859-1 Stephen Kent : Some folks believed that I was arguing that ChaCha needed to > use pseudorandom IVs, generated within the cryptography module boundary. > The slides do not say this. It would be fine to use a counter or a LFSR to > generate a unique sequence of IVs for ChaCha. The requirement, I stated, > was that this be performed within the evaluation (module) boundary. So, one > might use a counter for IVs in a module, and yes, that might duplicate the > sequence numbers already used by a protocol like TLS or ESP. This wastes > space in each packet, but we already live with it in ESP and in other > cryptography algorithm / mode combinations in DTLS. Thanks for clarifying! Watson Ladd : Secondly, I don't see why a module that uses a counter as an IV cannot > output it in the right place to be a TLS sequence number. Or rather, if you have a module that generates sequence-number IVs internally, why do you have to transmit that IV at the particular location where it was output, instead of (external to that module) "compressing" the data for TLS usage by checking that the CTR mode IV sequence number agrees with the TLS record sequence number and then omitting it from the ciphertext? (This is logically equivalent to having the counter outside the module and checking explicitly provided IVs against the expected value within the module as I proposed earlier, but literally adheres to the restriction that "The external generation of the IVs is not allowed.") --20cf3005137850167504f3f450ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Stephen Kent <kent@bbn.com>:

=A0 =A0 =A0 =A0 =A0 =A0=A0Some folks believed that I was argu= ing that ChaCha needed to use pseudorandom IVs, generated within the crypto= graphy module boundary. The slides do not say this. It would be fine to use= a counter or a LFSR to generate a unique sequence of IVs for ChaCha. The r= equirement, I stated, was that this be performed within the evaluation (mod= ule) boundary. So, one might use a counter for IVs in a module, and yes, th= at might duplicate the sequence numbers already used by a protocol like TLS= or ESP. This wastes space in each packet, but we already live with it in E= SP and in other cryptography algorithm / mode combinations in DTLS.<= /blockquote>

Thanks for clarifying!=A0


Watson Ladd <watsonbladd@gmail.c= om>:

Secondly, I don't see why a module that uses a counter as an IV cannot<= br> output it in the right place to be a TLS sequence number.
=
Or rather, if you have a module that generates sequence-numb= er IVs internally, why do you have to transmit that IV at the particular lo= cation where it was output, instead of (external to that module) "comp= ressing" the data for TLS usage by checking that the CTR mode IV seque= nce number agrees with the TLS record sequence number and then omitting it = from the ciphertext?

(This is logically equivalent to having the counter out= side the module and checking explicitly provided IVs against the expected v= alue within the module as I proposed earlier, but literally adheres to the = restriction that "The external generation of the IVs is not allowed.&q= uot;)

--20cf3005137850167504f3f450ab-- From nobody Thu Mar 6 11:03:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7931A010A for ; Thu, 6 Mar 2014 11:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 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, HELO_EQ_DE=0.35, HTML_MESSAGE=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 nAHWJUji5SGK for ; Thu, 6 Mar 2014 11:02:58 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) by ietfa.amsl.com (Postfix) with ESMTP id 890D71A0088 for ; Thu, 6 Mar 2014 11:02:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1394132573; l=7000; s=domk; d=sandeep.de; h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To: MIME-Version:X-RZG-CLASS-ID:X-RZG-AUTH; bh=QJ+egZewgRp00lmR3MYpOX+lnGU=; b=Fa5yKYhhfPIi0FsfMPy1o1ynTdjeh9tVU8zhl/gRBVk3Tfq1yua8cqnGCdGHKTDFz0V +3z9wmtrwvbdlRBsYfZSz7peLX0q+MsQFsNenfKvzb+SZ+xH7AU8+OiUdwVNcx9+nSzGy RFQrgKmk0kaGq4kbwOQhvnhjMqz1wjQgjuI= X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkNEKLhUifTGQSE4QZmtyQ X-RZG-CLASS-ID: mo00 Received: from mail-qc0-f176.google.com ([209.85.216.176]) by smtp.strato.de (RZmta 32.27 AUTH) with ESMTPSA id j074e1q26J2o1pQ (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verification FAILED - certificate not trusted)) (Client hostname not verified) for ; Thu, 6 Mar 2014 20:02:50 +0100 (CET) Received: by mail-qc0-f176.google.com with SMTP id m20so3400410qcx.21 for ; Thu, 06 Mar 2014 11:02:49 -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=PTL/h2nwy+lZpLti+QrfQEwE1saTWyGbzw28wed2bDA=; b=bvQavUwB98hwd7WTBeqTY91emgY3S7lC06q9pI1jmfqBfwDJrcUpCAj7azToVK0LOk 9bhmemEc/tzapLzWkSvBnL002cDTDgjnB/3q7KDXF3REoU+WX7C77DBk08rJI7UI+6iv 9GW4LBmVAXIsE9DeF1uzwTpfxSRaP8EYt+fDM+yXGcOtNCIuaiRmEkPJCD/hW9KFh20g URGIZiyrGPscuxR9huwvUxmisvVy0ioaOhLbRP0DrLuGrpRDAROOt146d1KNZnNti39C SDsAFiDmW7JqXePO4RcZm8k4SGISKw405eyH6q9Um7UDmc/e/yq6JM1Ss+bLLBLi+0T6 TF1Q== MIME-Version: 1.0 X-Received: by 10.140.33.132 with SMTP id j4mr15187573qgj.97.1394132569436; Thu, 06 Mar 2014 11:02:49 -0800 (PST) Received: by 10.224.32.73 with HTTP; Thu, 6 Mar 2014 11:02:49 -0800 (PST) In-Reply-To: References: <5318A8A6.50201@bbn.com> Date: Thu, 6 Mar 2014 20:02:49 +0100 Message-ID: From: Sandeep Kumar To: Bodo Moeller Content-Type: multipart/alternative; boundary=001a113ac228925dab04f3f4c8ed Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XkNedQYOYs5NTzVD-QvX1nuMhe8 Cc: Stephen Kent , "tls@ietf.org" Subject: Re: [TLS] where IVs come from (and other mysteries ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 19:03:01 -0000 --001a113ac228925dab04f3f4c8ed Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 6, 2014 at 7:29 PM, Bodo Moeller wrote: > Stephen Kent : > > Some folks believed that I was arguing that ChaCha needed to >> use pseudorandom IVs, generated within the cryptography module boundary. >> The slides do not say this. It would be fine to use a counter or a LFSR to >> generate a unique sequence of IVs for ChaCha. The requirement, I stated, >> was that this be performed within the evaluation (module) boundary. So, one >> might use a counter for IVs in a module, and yes, that might duplicate the >> sequence numbers already used by a protocol like TLS or ESP. This wastes >> space in each packet, but we already live with it in ESP and in other >> cryptography algorithm / mode combinations in DTLS. > > > Thanks for clarifying! > > > Watson Ladd : > > Secondly, I don't see why a module that uses a counter as an IV cannot >> output it in the right place to be a TLS sequence number. > > > Or rather, if you have a module that generates sequence-number IVs > internally, why do you have to transmit that IV at the particular location > where it was output, instead of (external to that module) "compressing" the > data for TLS usage by checking that the CTR mode IV sequence number agrees > with the TLS record sequence number and then omitting it from the > ciphertext? > > (This is logically equivalent to having the counter outside the module and > checking explicitly provided IVs against the expected value within the > module as I proposed earlier, but literally adheres to the restriction that > "The external generation of the IVs is not allowed.") > > > RFC5288 states that struct { opaque salt[4]; opaque nonce_explicit[8]; } GCMNonce; ...the salt is generated as part of the handshake process: it is either the client_write_IV (when the client is sending) or the server_write_IV (when the server is sending). Does it mean that the module generates the nonce_explicit or the whole GCMNonce. If it's the latter then the sequence number checking on the TLS packet will not help. Sandeep > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a113ac228925dab04f3f4c8ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 6, 2014 at 7:29 PM, Bodo Moeller <= bmoeller@acm.org&= gt; wrote:
Ste= phen Kent <kent@bbn.co= m>:

=A0 =A0 =A0 =A0 =A0 =A0=A0Some folks believed that I was argu= ing that ChaCha needed to use pseudorandom IVs, generated within the crypto= graphy module boundary. The slides do not say this. It would be fine to use= a counter or a LFSR to generate a unique sequence of IVs for ChaCha. The r= equirement, I stated, was that this be performed within the evaluation (mod= ule) boundary. So, one might use a counter for IVs in a module, and yes, th= at might duplicate the sequence numbers already used by a protocol like TLS= or ESP. This wastes space in each packet, but we already live with it in E= SP and in other cryptography algorithm / mode combinations in DTLS.<= /blockquote>

Thanks for clarifying!=A0


Watson Ladd &= lt;watsonbladd@g= mail.com>:

Secondly, I don't see why a module that uses a counter as an IV cannot<= br> output it in the right place to be a TLS sequence number.
=
Or rather, if you have a module that generates sequenc= e-number IVs internally, why do you have to transmit that IV at the particu= lar location where it was output, instead of (external to that module) &quo= t;compressing" the data for TLS usage by checking that the CTR mode IV= sequence number agrees with the TLS record sequence number and then omitti= ng it from the ciphertext?

(This is logically equivalent to having the counter out= side the module and checking explicitly provided IVs against the expected v= alue within the module as I proposed earlier, but literally adheres to the = restriction that "The external generation of the IVs is not allowed.&q= uot;)




RFC5288 states that
=A0=A0 struct {
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 op= aque salt[4];
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 opaque nonce= _explicit[8];
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 } GCMNonce;

..= .the salt is generated as part of the handshake
=A0=A0 process: it is either the client_write_IV (when the client is
=A0= =A0 sending) or the server_write_IV (when the server is sending).=A0=A0

Does it mean that the module generates the nonce_expl= icit or the whole GCMNonce. If=A0it's the latter then the sequence numb= er checking on the=A0TLS packet will not help.

Sandeep=A0
______________________= _________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--001a113ac228925dab04f3f4c8ed-- From nobody Thu Mar 6 11:14:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1B71A0168 for ; Thu, 6 Mar 2014 11:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0UAisbYLKHz for ; Thu, 6 Mar 2014 11:14:14 -0800 (PST) Received: from claranet-outbound-smtp06.uk.clara.net (claranet-outbound-smtp06.uk.clara.net [195.8.89.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3F79E1A010A for ; Thu, 6 Mar 2014 11:14:13 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:54368 helo=[192.168.7.9]) by relay16.mail.eu.clara.net (relay.clara.net [81.171.239.36]:10465) with esmtpa (authdaemon_plain:drh) id 1WLdk1-00006t-KG for tls@ietf.org (return-path ); Thu, 06 Mar 2014 19:14:01 +0000 Message-ID: <5318C8F4.5070603@drh-consultancy.co.uk> Date: Thu, 06 Mar 2014 19:13:56 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <5318A8A6.50201@bbn.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VEkFi7xMHwD3y5kFVpocEmeC-kE Subject: Re: [TLS] where IVs come from (and other mysteries ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 19:14:17 -0000 On 06/03/2014 19:02, Sandeep Kumar wrote: > > RFC5288 states that > struct { > opaque salt[4]; > opaque nonce_explicit[8]; > } GCMNonce; > > ...the salt is generated as part of the handshake > process: it is either the client_write_IV (when the client is > sending) or the server_write_IV (when the server is sending). > > Does it mean that the module generates the nonce_explicit or the whole GCMNonce. > If it's the latter then the sequence number checking on the TLS packet will not > help. > When I first looked through the specs I thought the module was required to generate the whole of GCMNonce but that would make TLS 1.2 use of AES GCM with FIPS140-2 impossible as the salt part comes from the PRF. Fortunately one of the permissible schemes allows the salt part to be specified by the API and only requires generation of the nonce_explicit part. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nobody Thu Mar 6 11:18:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7437A1A01AF for ; Thu, 6 Mar 2014 11:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj19p0yuQjge for ; Thu, 6 Mar 2014 11:18:52 -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 ABC221A0160 for ; Thu, 6 Mar 2014 11:18:52 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A4CC9480E5; Thu, 6 Mar 2014 19:18:48 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (unknown [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 996A9480C0; Thu, 6 Mar 2014 19:18:48 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 7E4FA9803D; Thu, 6 Mar 2014 19:18:48 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.104]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Thu, 6 Mar 2014 14:18:47 -0500 From: "Salz, Rich" To: Watson Ladd Date: Thu, 6 Mar 2014 14:18:45 -0500 Thread-Topic: [TLS] where IVs come from (and other mysteries ...) Thread-Index: Ac85ZxtWRyqoqjuLSISz0rpEpoIIygAByjyQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AABB7@USMBX1.msg.corp.akamai.com> References: <5318A8A6.50201@bbn.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AAB0B@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Xj0Vnj7kTYKu5mA4uR6SK9yPnOM Cc: "tls@ietf.org" Subject: Re: [TLS] where IVs come from (and other mysteries ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 19:18:54 -0000 PiB3aHkgbWVldGluZyBpdCBpbmNyZWFzZXMgY29uZmlkZW5jZSBpbiB0aGUgcHJvcGVydHkgd2Ug YWN0dWFsbHkgY2FyZSBhYm91dCwgbmFtZWx5IGNvcnJlY3RuZXNzIG9mIHRoZSBlbnRpcmUgaW1w bGVtZW50YXRpb24uIEl0J3MgcGFydGljdWxhcmx5DQo+IGEgcHJvYmxlbSB3aGVuIHRoZSBnb2Fs IGlzIHJlbmRlcmluZyB0aGUgY2VydGlmaWNhdGlvbiBtZWFuaW5nbGVzcyBieSBleGNsdWRpbmcg YXMgbXVjaCBhcyBwb3NzaWJsZSBmcm9tIHRoZSBzY29wZS4gU3Vic3RhbmNlIG1hdHRlcnMuDQoN CkV2YWx1YXRpb25zIGFyZSB0aW1lLWNvbnN1bWluZyBhbmQgZXhwZW5zaXZlLiBHbyBhc2sgb24g dGhlIE9wZW5TU0wgbGlzdCBob3cgbXVjaCBpdCBjb3N0IHRvIGdldCB0aGVpciBzdGFjayBjZXJ0 aWZpZWQuICBJIHdvdWxkbid0IHdhbnQgdG8gZ3Vlc3MgdGhlIGNvc3QgaWYgeW91J3JlIHN0YXJ0 aW5nIGZyb20gc2NyYXRjaCB3aXRoIGEgVExTIGltcGxlbWVudGF0aW9uLg0KDQo+U3VyZSwgYnV0 IEkgZG9uJ3QgcXVpdGUgYXBwcmVjaWF0ZSB3aHkgdGhlIG1vZHVsZSBjYW4ndCBnZW5lcmF0ZSB0 aGUgVExTIHNlcXVlbmNlIG51bWJlciBpdHNlbGYuDQoNCkkgZG9uJ3Qga25vdyBpZiBhIGNlcnRp ZmllZCBtb2R1bGUgaXMgYWxsb3dlZCB0byAiZ2l2ZSBvdXQiIHRoZSBJViwgb3IgaWYgaXQncyBv bmx5IGFsbG93ZWQgdG8gZ2l2ZSBvdXQgdGhlIHBsYWludGV4dC4NCg0KPiBJcyB0aGVyZSBzb21l IGNvbXBsaWNhdGVkIGludGVyYWN0aW9uIG9mIHNwZWNzIHRoYXQgSSdtIG5lZ2xlY3Rpbmc/DQoN CldlbGwsIGFzIGEgc3RhcnQsIGl0IGNlcnRhaW5seSBhcHBlYXJzIHRoYXQgeW91IGFyZSB1bmZh bWlsaWFyIHdpdGggRklQUyBldmFsdWF0aW9uLg0KDQo+PiBBbmQgZXZhbHVhdGlvbiBpc24ndCBh IGNvZGUgcmV2aWV3IGFuZCB3aWxsIG5vdCAobmVjZXNzYXJpbHkpIGZpbmQgYnVncy4NCj4NCj4g U28gaXQncyBhIGxpdHRsZSBzdGlja2VyIHNheWluZyAiV2UgZGlkIG5vdGhpbmcgdG8gc2hvdyB0 aGlzIHdvcmtzLiBIYXZlIGZ1biEiPw0KDQpJIG5ldmVyIHNhaWQgdGhhdC4gIEFuZCBob3cgbXVj aCBkbyB5b3Ugd2FycmFudCB5b3VyIHNvZnR3YXJlPyA6KSAgRm9yIGEgbGVzcyBmbGlwIGFuc3dl ciwgc3RhcnQgaGVyZTogaHR0cDovL2NzcmMubmlzdC5nb3YvZ3JvdXBzL1NUTS9jbXZwL2RvY3Vt ZW50cy8xNDAtMS8xNDB2YWwtYWxsLmh0bQ0KDQoNCgkvciQNCg0KLS0gIA0KUHJpbmNpcGFsIFNl Y3VyaXR5IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5vbG9neQ0KQ2FtYnJpZGdlLCBNQQ0K From nobody Thu Mar 6 12:19:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F26A1A00E9 for ; Thu, 6 Mar 2014 12:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 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.547, 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 FJ48-XN7rBY7 for ; Thu, 6 Mar 2014 12:19:09 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBBE1A0084 for ; Thu, 6 Mar 2014 12:19:08 -0800 (PST) Received: from mail-yh0-f41.google.com (mail-yh0-f41.google.com [209.85.213.41]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0M40UE-1XCndl47aE-00razL; Thu, 06 Mar 2014 21:19:04 +0100 Received: by mail-yh0-f41.google.com with SMTP id f73so3277442yha.0 for ; Thu, 06 Mar 2014 12:19:03 -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=8qxeCOaOtIAjjTGvEq+jSj/nnuXu97o2u6wmS5mrScs=; b=CP+hBunzLB1azq+2DHY31KBZBRypUvtkxgft8vyYGQJk5Q3W626o/AB4KSrp7WrEuQ bWIbcc8+JyemvSAmuVWrE8mQCi1h4H5bqV9CBv1gBFmXdHdFB0MfQdqAOci/khfekgWn yxsQwYGnDKT2b6BJwxKCrYHpUqtOK0ftfJK+a7MDFdlS16XRh60BYiOayPSBnGMsZVpL 42G2F5eKCuYGQJwH0EUtetQZI7Saf/gDfuB+8TBS9GUtnpZQqmoRAZ/jZ/oS8pqjsyVV 8tBSsXfjDU+cLbAWF2RbGC7UNGd2vDjYLw2x0TdUuHYGlnVS3DPkWdw4gRTx+tbMdQnJ 4tgQ== MIME-Version: 1.0 X-Received: by 10.236.75.74 with SMTP id y50mr17545311yhd.27.1394137143015; Thu, 06 Mar 2014 12:19:03 -0800 (PST) Received: by 10.170.78.5 with HTTP; Thu, 6 Mar 2014 12:19:02 -0800 (PST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AABB7@USMBX1.msg.corp.akamai.com> References: <5318A8A6.50201@bbn.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AAB0B@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AABB7@USMBX1.msg.corp.akamai.com> Date: Thu, 6 Mar 2014 12:19:02 -0800 Message-ID: From: Bodo Moeller To: "Salz, Rich" Content-Type: multipart/alternative; boundary=20cf300513782d824304f3f5d94e X-Provags-ID: V02:K0:7mTEM3oLWKbFjnIHw4SWTqJjnCNrLdp0zMAf78maEgn +FUtOb5D9hKHMxG8pTIC5Pn0LpmMB1b4YsvMPBNU0bgpTZ8JNP 6+dCOKlfXVcCpPbp5NtGkuEWu+F2JgqVMhHhxQ75OhwykLFK0e 6g2DEhAlXoXTUKKkMgfnBlFrC292uhdT4hm7r3YAuPAr529ZS2 Gu9ANt9ISPW1eeYvD7C491cG7knfhoi3DhcxhoyD3flZZ4NhZf 27EsQ6tU1aKlxpY1ltWQRg+zV21qOevD5JJxsCGNMBkdcEbxb9 RLuquz1vIFgtuRXAgKCvgYbI4eqP9OBnKrvHvHTOV1JHj0TCs6 tg07SRNGH1F3D93vXXGcwJmyUA/M3BG3ep2Ujfj54hqyt1DsOb klWM+2L1NY/4CkTrpwl/bV9I4Yu0RAdgvR4t6qpMwAttPuhMGt r0Ny8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XWYo2N9ielnzISPH4hSPGOvDsdU Cc: "tls@ietf.org" Subject: Re: [TLS] where IVs come from (and other mysteries ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 20:19:10 -0000 --20cf300513782d824304f3f5d94e Content-Type: text/plain; charset=ISO-8859-1 Salz, Rich : I don't know if a certified module is allowed to "give out" the IV, or if > it's only allowed to give out the plaintext. > I'm not quite sure what you mean here. When encrypting, if the module generates the IV in an unpredictable way, it will have to output that IV because we need to provide it to the recipient. When decrypting, the IV will have to be provided to the module. There's no need for the module to output that IV because it's part of the input anyway. Bodo --20cf300513782d824304f3f5d94e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Salz= , Rich <rsalz@akamai.com>:
I don't know if a certified module is allowed to "give out" t= he IV, or if it's only allowed to give out the plaintext.

I'm not quite sure what you mean here.

When encrypting, if the module generates the IV in an u= npredictable way, it will have to output that IV because we need to provide= it to the recipient.

When decrypting, the IV will= have to be provided to the module. =A0There's no need for the module t= o output that IV because it's part of the input anyway.

Bodo

--20cf300513782d824304f3f5d94e-- From nobody Thu Mar 6 15:15:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E901A00CA for ; Thu, 6 Mar 2014 15:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 654h-RAWMc6J for ; Thu, 6 Mar 2014 15:15:39 -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 CDB3B1A0043 for ; Thu, 6 Mar 2014 15:15:39 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7D75A480E2; Thu, 6 Mar 2014 23:15:35 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (unknown [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 70CD6480AB; Thu, 6 Mar 2014 23:15:35 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 434911E03D; Thu, 6 Mar 2014 23:15:35 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.104]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Thu, 6 Mar 2014 18:15:34 -0500 From: "Salz, Rich" To: Bodo Moeller Date: Thu, 6 Mar 2014 18:15:32 -0500 Thread-Topic: [TLS] where IVs come from (and other mysteries ...) Thread-Index: Ac85eVSU2AkUN32jRq+69wTMRjjo1gAGHZqg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AAD0B@USMBX1.msg.corp.akamai.com> References: <5318A8A6.50201@bbn.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AAB0B@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AABB7@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: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C711FB9AAD0BUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pjoMRqwJAYoNbXb1MICW0cNXp1w Cc: "tls@ietf.org" Subject: Re: [TLS] where IVs come from (and other mysteries ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Mar 2014 23:15:42 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C711FB9AAD0BUSMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I'm not quite sure what you mean here. Yeah, I don't know what I meant either. I'll blame jetlag and ... somethin= g else, not sure what. Sorry 'bout that. -- Principal Security Engineer Akamai Technology Cambridge, MA --_000_2A0EFB9C05D0164E98F19BB0AF3708C711FB9AAD0BUSMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> I'm not qui= te sure what you mean here.

 

Yeah, I don’t kno= w what I meant either.  I’ll blame jetlag and … something = else, not sure what.  Sorry ‘bout that.

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>-- 

Principal = Security Engineer

Akamai T= echnology

Cambridge, MA

 

=
= --_000_2A0EFB9C05D0164E98F19BB0AF3708C711FB9AAD0BUSMBX1msgcorp_-- From nobody Fri Mar 7 01:31:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839C71A0285 for ; Fri, 7 Mar 2014 01:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 vj4iC7oe4lZd for ; Fri, 7 Mar 2014 01:31:02 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 72C1B1A0164 for ; Fri, 7 Mar 2014 01:30:53 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:50160 helo=dhcp-a3d7.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WLr79-000FU0-Uc; Fri, 07 Mar 2014 04:30:48 -0500 Message-ID: <531991C7.308@bbn.com> Date: Fri, 07 Mar 2014 04:30:47 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Watson Ladd References: <5318A8A6.50201@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KMHCZuXQQR27HCzHmrfeeWvZwis Cc: "tls@ietf.org" Subject: Re: [TLS] where IVs come from (and other mysteries ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 09:31:04 -0000 Watson, > What is the value of evaluation if it does not include the entire TLS > stack? The bugs are not living in the core crypto modules which are > easily tested: they live at a higher level. Eval is performed by NIST for algs and modes, focusing on correctness of the implementation, protection of keys, etc. There is no eval criteria for TLS, nor IPsec, etc. So, while it's true that we really want a security protocol to work securely, that's not an option in most cases. The motivation for a vendor to have a product evaluated, relative to NIST criteria, is that this makes the product easier for US Gov folks to purchase. The bigger the collection of SW, firmware, or HW that has to be evaluated, the longer it takes, the more it costs, and the faster the eval becomes invalid, because you made a change to the evaluated stuff (even for reasons largely irrelevant to the core security functions). > Secondly, I don't see why a module that uses a counter as an IV cannot > output it in the right place to be a TLS sequence number. Yes, this > restricts the module design, but it doesn't prevent compliance with > the NIST requirements. Well, you might be able to do that, but the receiver would have to know that it has to take the sequence number and use it as the IV, right? That would have to be negotiated, if one is to allow other IV generation approaches as well. Steve From nobody Fri Mar 7 01:38:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A9C1A0255 for ; Fri, 7 Mar 2014 01:38:52 -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 2G_AfxfuIZTF for ; Fri, 7 Mar 2014 01:38:51 -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 B76A91A026A for ; Fri, 7 Mar 2014 01:38:50 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id x13so4667816wgg.21 for ; Fri, 07 Mar 2014 01:38:46 -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=PDhV0tAXadaFzg8R+gTQLQYRpunqp4+5Et7gmqwdBJM=; b=grFrvaD8DgKRZ5gXDe2qSAaAkGyXyBb7enOUOTPmWVffOwoccYf/KdC/UFHFH9Yetj 6WfbGDUJD3kYBZ45btH7GCvarhZyROItbWBCPnlMH+B0BSvX52S4Eu5/JiuLMtpFNLEm Xdy22hDK12fbxYPROLbjizmdLzI31SLyhBmoD0tRye3GyuI71ovMq7Q6EP9Ho+j/OLv3 Xf0kfm+XVVR7Dea0SYYi0MHXGFjl8y19POXkhTJmInW+14PpP8g6EOLyVL743m6AkUsA egujNEF4bdUwsm7FtFdqxqgvbpuFpsXL3jFmzJgZEv9rx/8pxgl+duYhO5A+RQPZDu1A rloA== MIME-Version: 1.0 X-Received: by 10.194.110.41 with SMTP id hx9mr17609664wjb.28.1394185126118; Fri, 07 Mar 2014 01:38:46 -0800 (PST) Received: by 10.227.10.196 with HTTP; Fri, 7 Mar 2014 01:38:46 -0800 (PST) In-Reply-To: <20140306110100.5058.89585.idtracker@ietfa.amsl.com> References: <20140306110100.5058.89585.idtracker@ietfa.amsl.com> Date: Fri, 7 Mar 2014 09:38:46 +0000 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Q6dqandMAKSHHljeFMQvMQEsTXg Subject: [TLS] Fwd: New Version Notification for draft-thomson-tls-acp-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, 07 Mar 2014 09:38:52 -0000 Just so that folks don't wonder about what this is about, there's a thread in rtcweb@ that I've started on the topic. This extension might be required to support some security features in WebRTC. For those interested, there is some more context in this thread: http://www.ietf.org/mail-archive/web/rtcweb/current/msg11755.html ---------- Forwarded message ---------- Name: draft-thomson-tls-acp Revision: 00 Title: Authenticated Content Promise Extension for (D)TLS Document date: 2014-03-06 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-thomson-tls-acp-00.txt Status: https://datatracker.ietf.org/doc/draft-thomson-tls-acp/ Htmlized: http://tools.ietf.org/html/draft-thomson-tls-acp-00 Abstract: This document describes an extension to Transport Layer Security (TLS) and Datagram TLS (DTLS) that enables the negotiation of a promise to protect session content from modification and eavesdropping by third parties. From nobody Fri Mar 7 01:45:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50B11A0164 for ; Fri, 7 Mar 2014 01:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.699 X-Spam-Level: ** X-Spam-Status: No, score=2.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o7tWUbUMW4H for ; Fri, 7 Mar 2014 01:45:51 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id B5CC01A018F for ; Fri, 7 Mar 2014 01:45:49 -0800 (PST) Received: from localhost (91-64-48-103-dynip.superkabel.de [::ffff:91.64.48.103]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Fri, 07 Mar 2014 10:45:44 +0100 id 0000000000020052.0000000053199548.00004518 Date: Fri, 7 Mar 2014 10:45:13 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20140307104513.545b3c33@hboeck.de> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-17688-1394185545-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iA8RGp1_95JVtwpJNJTC_96eH6c Subject: [TLS] DH parameters, primality X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 09:45:53 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-17688-1394185545-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Recently two issues brought DH parameters to my attention. First, it was mentioned in the triple handshake issue that a server sending malicious DH parameters could cause trouble. And second a crash in chrome was detected when using it with very short DH parameters. So I did some tests on that you might be interested in: https://dh.tlsfun.de/ I wrote up a bit about my findings here: http://blog.hboeck.de/archives/841-Diffie-Hellman-and-TLS-with-nonsense-par= ameters.html tl;dr Probably not many people have tested these things in the past. Using obviously wrong parameters could uncover other bugs. Some browsers (and other tls clients) accept all kinds of bogus parameters for DH. No browser checks for primality. What conclusions to draw from all that for TLS? First I would propse that all DH parameters below 1024 bit get rejected. I don't see any valid reason for them. (I'd prefer to say here that < 2048 bit should be rejected, but I'm aware that this is not realistic for quite some time considering the implementations out there). I'd expect rejecting < 1024 bit exchanges to have very low impact, as opera already doesn't like to connect to them. The more difficult part is if primality should be tested in some way. The finders of the triple handshake issue propose to define a number of good primes. This is a good idea, but it doesn't solve the problem for connections with existing implementations. Currently, most DH exchanges are still 1024 bit. Primality tests for them are feasible. However, for 2048 bit they're challenging and for 4096 probably not feasible at all (about 1 second on my core2). Maybe it would be possible to run a miller rabin test with less rounds and have a "high probability prime" and consider that good enough? Another option would be to define some fixed "good" primes now and try to get them out quickly. As currently DH exchanges with 2048/4096 bit are rare, it could probably avoided that arbitrary primes get widely deployed. Then browsers could test either if they see a known good prime (fast) and if not test primality. The performance impact would probably be acceptable if the event of getting a 2048/4096 prime is rare. Thoughts? cu, --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-17688-1394185545-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJTGZUpAAoJEKWIAHK7tR5ChFQP+gPzKqO076FdU+Alyfl1d/cq I9jYimu+wH16L1ZyImvUmhpuWhWKw0VwrkU2Ok+LxiXLIw24K60gRbAGTieH1+UB B0n9h4i6m2HgYmfGKVGli90n7HXfjQ2PNT+TLrFL2nlxexHgqz2l1B2nsQogWs84 0N+XDfZvHF7grWvUQ8mpDKUBg0Xy8o/Vqmt4/7dcdtPyIN2DjJlPWCAe35f+2hht bGIwaLWK1r57Ji/K+KFh9Uc7v7m7h9Xh6lTmYownmja8AqQLFIuK9RLDLkjwyjf2 1ah7Yy4GGLJDHPP8IoFCOcxcaRHE6zA38zAqEZBwMhj+iCzlf5oQt/sz+Vcy6vo3 EjSMj3zjbYfem9301URLrvFytEU7+PyZa0+I7kPOUmC0CFC5Oj3voWsnhifVV2aH 3Wx6GTtkiXj8mxCbKZWH41FB3cXQ9boJg4iKPS3bm3dViw9f0DqJxsgXGGrZCszR BAWVqL96x5tIU/FjUTfN9KKt/7pXz/vH/I0Oh3Vs86DxxOWJbIKIh7cqeEjmhUsY UMgOXSAtAEUyRL/3uPiuGqBOCYnjqhzQO/ovps/6RqzX80LtqEk3V2cJ7SVUeRn5 yYDXKe0Ejk/XgHlEC4tDe051A4Ks+ynLkk8DrQBADW+Vv2s+VZvSHybgHIAPp5F0 f5MjczR5sYhvE8tJWhIs =GbD9 -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-17688-1394185545-0001-2-- From nobody Fri Mar 7 02:18:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DBD1A0170 for ; Fri, 7 Mar 2014 02:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 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, MANGLED_BACK=2.3, 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 WvT0rGvQPnvP for ; Fri, 7 Mar 2014 02:18:00 -0800 (PST) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D57901A0133 for ; Fri, 7 Mar 2014 02:17:59 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id f11so3793623qae.3 for ; Fri, 07 Mar 2014 02:17:55 -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 :content-transfer-encoding; bh=/+C7j4z6oVrgcxmPTdHCSpWNDN8K81BXpG304EWFo7Q=; b=0mmh8QLZMaIIZOzcUziuOLDGzwDUmE2fjiO5GHVHxQus7culOqleFTgFmoAHMM1F5r duQtgfzYkG2H+R8mIxUT4EiF1EA31k6vYqM897zoAqk4dw6Kisjrp6YUNw8CThTQhTcu +bQx5u3ZzQFhUlh9WMNC7RRDFjGRK2xeu6Eam+nLKKdmut3r6DAmNkFyfTVOSOcdDH/L tpDq97wgrpOUwJHdRgoIPM7Zadg+sxi/YjK2vmd7zhvSM+gayDSkbNmadfAPbiYcsA6M hPjHklvZ8mhWAW5M6To0h8+9n9X+PSqcseOboORJqqOOMtZyxryili1FXaZPorYNz7Nx PxYQ== MIME-Version: 1.0 X-Received: by 10.224.103.197 with SMTP id l5mr20568632qao.69.1394187475385; Fri, 07 Mar 2014 02:17:55 -0800 (PST) Received: by 10.224.32.18 with HTTP; Fri, 7 Mar 2014 02:17:55 -0800 (PST) Date: Fri, 7 Mar 2014 10:17:55 +0000 Message-ID: From: Joseph Birr-Pixton To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pHDkF8_FWIhzlhli3cebzBs5MH4 Cc: tls@ietf.org Subject: Re: [TLS] DH parameters, primality X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 10:18:00 -0000 On 7 March 2014 09:45, Hanno B=C3=B6ck wrote: > ---------- Forwarded message ---------- > From: Hanno B=C3=B6ck > To: tls@ietf.org > Cc: > Date: Fri, 7 Mar 2014 10:45:13 +0100 > Subject: [TLS] DH parameters, primality > > The more difficult part is if primality should be tested in some way. > The finders of the triple handshake issue propose to define a number > of good primes. This is a good idea, but it doesn't solve the problem > for connections with existing implementations. > Currently, most DH exchanges are still 1024 bit. Primality tests for > them are feasible. However, for 2048 bit they're challenging and for > 4096 probably not feasible at all (about 1 second on my core2). > > Maybe it would be possible to run a miller rabin test with less rounds > and have a "high probability prime" and consider that good enough? Since these primes are adversarially chosen, you need to choose drastically many more RM rounds to get even a "high probability prime". To be clear: most of the primality tests you'll find in your crypto library or textbook only deal with randomly chosen candidates. Cheers, Joe From nobody Fri Mar 7 02:30:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9651A021F for ; Fri, 7 Mar 2014 02:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.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 wiaq20g77yF0 for ; Fri, 7 Mar 2014 02:30:33 -0800 (PST) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by ietfa.amsl.com (Postfix) with ESMTP id A26C11A01E0 for ; Fri, 7 Mar 2014 02:30:33 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id DDFA3699FF; Fri, 7 Mar 2014 12:30:27 +0200 (EET) Date: Fri, 7 Mar 2014 12:30:27 +0200 From: Ilari Liusvaara To: Joseph Birr-Pixton Message-ID: <20140307103027.GB16889@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iJpqy92C7uGLIiWU72KTe5iGWBQ Cc: tls@ietf.org Subject: Re: [TLS] DH parameters, primality X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 10:30:35 -0000 On Fri, Mar 07, 2014 at 10:17:55AM +0000, Joseph Birr-Pixton wrote: > On 7 March 2014 09:45, Hanno Böck wrote: > > Since these primes are adversarially chosen, you need to choose > drastically many more RM rounds to get even a "high probability > prime". I thought that if RM base is randomly chosen, it will pick composites with probability of 3/4 per iteration, no matter how the number to test to is picked. -Ilari From nobody Fri Mar 7 02:40:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855431A0230 for ; Fri, 7 Mar 2014 02:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_BACK=2.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 VQX2RUO1HMAe for ; Fri, 7 Mar 2014 02:40:13 -0800 (PST) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id EED7B1A01C4 for ; Fri, 7 Mar 2014 02:40:12 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id 6so901799bkj.10 for ; Fri, 07 Mar 2014 02:40:08 -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=GIoGQ0l8/Fpzt8HF3iEQi5Chxrs7bkTwmWiGNGSuiak=; b=oO7PSenUdZGIMd96XrECKJNIE780/I7j2goIHecBP7f77JpZhrxHC8ktL5OTw0OtRW ooUlhbFi02rzSK2dP4CPTyLJ8z4dIXfYjH+IFGgtDOy7tYxJGnLZGhxGgRpyrV8rJbPB 6xGQIWHLFpMAC+3eGUTxlK8k6Xkhvu9gmRcS6Ok3gKyifFHXzG/xzY2j1vGF4UEyaUta te6APF1k8/UX+uZhJuUwJ0LMvqOeI/J4DfcfswIOt4ChHGFyPYIdMBRUEQvtyWo4GjbT 3sXCIoY12tTnIUMKTqWoSgdxmZvAIH6/ldieQPi0yIW7UBv/QcxQ6KD58vxdWLYH+ZoM PnYw== X-Received: by 10.204.102.7 with SMTP id e7mr321180bko.84.1394188808173; Fri, 07 Mar 2014 02:40:08 -0800 (PST) Received: from [10.0.0.6] ([109.65.63.189]) by mx.google.com with ESMTPSA id xj2sm1835212bkb.15.2014.03.07.02.40.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Mar 2014 02:40:07 -0800 (PST) Message-ID: <5319A206.60906@gmail.com> Date: Fri, 07 Mar 2014 12:40:06 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ilari Liusvaara , Joseph Birr-Pixton References: <20140307103027.GB16889@LK-Perkele-VII> In-Reply-To: <20140307103027.GB16889@LK-Perkele-VII> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KbA9-531JdN1EGZqsesrw9edEFw Cc: tls@ietf.org Subject: Re: [TLS] DH parameters, primality X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 10:40:15 -0000 I'm far from an expert, but I seem to remember there are "pseudo primes" that will appear as prime to any Miller-Rabin test. I don't know how feasible it is for an attacker to generate such numbers. Thanks, Yaron On 03/07/2014 12:30 PM, Ilari Liusvaara wrote: > On Fri, Mar 07, 2014 at 10:17:55AM +0000, Joseph Birr-Pixton wrote: >> On 7 March 2014 09:45, Hanno Böck wrote: >> >> Since these primes are adversarially chosen, you need to choose >> drastically many more RM rounds to get even a "high probability >> prime". > > I thought that if RM base is randomly chosen, it will pick composites > with probability of 3/4 per iteration, no matter how the number to > test to is picked. > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Mar 7 02:54:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3386A1A01E1 for ; Fri, 7 Mar 2014 02:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.548 X-Spam-Level: X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMtsQEKTW8cQ for ; Fri, 7 Mar 2014 02:54:16 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3131A01EC for ; Fri, 7 Mar 2014 02:54:10 -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=1394189647; x=1425725647; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=owzyNcROry6dokfKbut5IJcfPcnLgbeRXyLaJ09i0rc=; b=B1XQxX1LIqUo58MmVpJd43xGJC6I7apM98wX+rv5iNpY3izROZXipXLP CtS9CLDl5PT+v9+PMsp0sAo0TO1uJ7HY8UZ+I0a0L1MULLUKQQr4D8UAj xnT95906bMUgXT4riOlWTJm9s4Myr9ATIMePVdQsf+Uh9uBm9a0eCuJHK Q=; X-IronPort-AV: E=Sophos;i="4.97,607,1389697200"; d="scan'208";a="238085051" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 07 Mar 2014 23:54:05 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Fri, 7 Mar 2014 23:54:05 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] DH parameters, primality Thread-Index: Ac85845Ti95ojICVRZaI4pMmSq1KGQ== Date: Fri, 7 Mar 2014 10:54:04 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7372387BE8@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IdVBUEBzga1N38leeDTLfbDqOic Subject: Re: [TLS] DH parameters, primality X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 10:54:18 -0000 Hanno =3D?UTF-8?B?QsO2Y2s=3D?=3D writes:=0A= =0A= >Probably not many people have tested these things in the past. Using=0A= >obviously wrong parameters could uncover other bugs. Some browsers (and ot= her=0A= >tls clients) accept all kinds of bogus parameters for DH. No browser check= s=0A= >for primality.=0A= =0A= You didn't try my code, did you? :-). OK, it's not a browser, but there ar= e=0A= implementations out there that won't just accept any old rubbish.=0A= =0A= (I recently found out about a TLS implementation that erroneously sent DH= =0A= primes with p =3D 0 to the other side and other implementations could conne= ct to=0A= it, I'm still waiting to hear back on what the implementations were).=0A= =0A= Peter.=0A= From nobody Fri Mar 7 02:56:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F8B1A00DC for ; Fri, 7 Mar 2014 02:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.4 X-Spam-Level: ** X-Spam-Status: No, score=2.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_PILL=2.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 GgsmHyfbZW_s for ; Fri, 7 Mar 2014 02:56:48 -0800 (PST) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id AD61B1A0079 for ; Fri, 7 Mar 2014 02:56:48 -0800 (PST) Received: (qmail 6519 invoked from network); 7 Mar 2014 10:56:45 -0000 Received: from pcdhz005.win.tue.nl (HELO hyperelliptic.org) (131.155.71.33) by mace.cs.uic.edu with SMTP; 7 Mar 2014 10:56:45 -0000 Received: (qmail 11753 invoked by uid 1000); 7 Mar 2014 10:56:42 -0000 Date: Fri, 7 Mar 2014 11:56:42 +0100 From: Tanja Lange To: Yaron Sheffer Message-ID: <20140307105642.GP5925@cph.win.tue.nl> References: <20140307103027.GB16889@LK-Perkele-VII> <5319A206.60906@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5319A206.60906@gmail.com> User-Agent: Mutt/1.5.11 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sRvS6lK7MPiLzsrqW_aZL6da_uk Cc: tls@ietf.org, Joseph Birr-Pixton Subject: Re: [TLS] DH parameters, primality X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 10:56:50 -0000 > I'm far from an expert, but I seem to remember there are "pseudo primes" > that will appear as prime to any Miller-Rabin test. I don't know how > feasible it is for an attacker to generate such numbers. > There are none for Miller Rabin, what you're thinking of is the Fermat test. You shold be fine with random tests but often bases are chosen deterministically s small primes in order -- this makes the computaitons somewhat cheaper. More constructively though, verifying primality given a certificate is much faster -- certificate here is not a CA kind of thing, it's what number theorists (and complexity theorists) call a statement that goes like this (using Pocklington as an example): p is prime because: * p_1 is prime, divides p-1, is larger than sqrt(p-1) and a1 is a base * p_2 is prime and divides p_1-1 and is larger than sqrt(p_1-1-1) and * a2 is a base ..... * 3 is a prime because I now it's a prime. Finiding the p_i costs time and effort, but verifying them is fast. Note that there are several versions of Pocklington's test and there is ECPP, so any number can be handled by these. All the best Tanja From nobody Fri Mar 7 03:01:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5336A1A00DC for ; Fri, 7 Mar 2014 03:01:35 -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 aYCJAaSIbNdB for ; Fri, 7 Mar 2014 03:01:34 -0800 (PST) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) by ietfa.amsl.com (Postfix) with ESMTP id F2DEC1A021B for ; Fri, 7 Mar 2014 03:01:33 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 665BE40A3; Fri, 7 Mar 2014 13:01:29 +0200 (EET) Date: Fri, 7 Mar 2014 13:01:28 +0200 From: Ilari Liusvaara To: Yaron Sheffer Message-ID: <20140307110128.GA18506@LK-Perkele-VII> References: <20140307103027.GB16889@LK-Perkele-VII> <5319A206.60906@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5319A206.60906@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/x0nFL91ZZd6nGbW_MV9Mu5E1M_c Cc: tls@ietf.org, Joseph Birr-Pixton Subject: Re: [TLS] DH parameters, primality X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 11:01:35 -0000 On Fri, Mar 07, 2014 at 12:40:06PM +0200, Yaron Sheffer wrote: > I'm far from an expert, but I seem to remember there are "pseudo > primes" that will appear as prime to any Miller-Rabin test. I don't > know how feasible it is for an attacker to generate such numbers. There are such pseudoprimes for Fermat test but not Miller-Rabin. Those pseudoprimes are known as "absolute pseudoprimes" or "Carmichael numbers". And then there are numbers that are primes, but are very weak as DH primes. -Ilari From nobody Fri Mar 7 03:30:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DEB1A0200 for ; Fri, 7 Mar 2014 03:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okmq6bahAejn for ; Fri, 7 Mar 2014 03:30:30 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAF41A01FC for ; Fri, 7 Mar 2014 03:30:29 -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=1394191826; x=1425727826; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=O8HgAqWsnl6KTwelh2QxzVb6a477nKEkQs0c2Mewto0=; b=Ko8hr50xGieqn5Y8WHi8lkCN6qPbJ6k42xgNt2sw3SUPoI0Ys+7QHhx4 Qz5UBmgTLKZw2/hcozz73zLMEO0rPlGGc6s84hrYfqSmePhdzalYLg8WN bm7lGsFbBgGPSyI9k98aNbMl+sHWUThLZZokEXu1qGAhtd7MYXyH0+NrK 8=; X-IronPort-AV: E=Sophos;i="4.97,607,1389697200"; d="scan'208";a="238087813" 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; 08 Mar 2014 00:30:25 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sat, 8 Mar 2014 00:30:24 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] DH parameters, primality Thread-Index: Ac85+KG8yXzWmirwQT6l5cCJg02faA== Date: Fri, 7 Mar 2014 11:30:24 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7372387C72@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jQ3hiEK_ZRACwu74niDhOEsCsjw Subject: Re: [TLS] DH parameters, primality X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 11:30:32 -0000 Tanja Lange writes:=0A= =0A= >More constructively though, verifying primality given a certificate is muc= h=0A= >faster =0A= =0A= A quick fix for TLS would be to switch from the current PKCS #3-style DH=0A= representation to FIPS 186-style, for which you can verify the parameters= =0A= using Kravitz' kosherizer. This was proposed some time ago but didn't get= =0A= much too much acceptance, maybe it's time to revisit it...=0A= =0A= Peter.=0A= From nobody Fri Mar 7 03:46:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287BF1A01E0 for ; Fri, 7 Mar 2014 03:46:36 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, 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 21q7u29Ww3_G for ; Fri, 7 Mar 2014 03:46:34 -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 5768A1A018F for ; Fri, 7 Mar 2014 03:46:34 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id t60so4824628wes.33 for ; Fri, 07 Mar 2014 03:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=M1VUh9Bga/pqwt5lRZD0HDrv2A26Yy1UO6ZkgT7Q1gM=; b=E3CcfLh3XafkPEzMPqhVffZgu+HtJMh/dT4GM9kfjSx07OTLECTdK1kdExShdajH7w T6DZ8iX6/sf6SfDLDYJOw755Jd4RUt+3L06UC1qyzahrqLCxZZeIvea3k65PZsBVj7Mf ZmVSW7yU1EEcdC6zBnEb50HeJnHifxDGhJZYdb/fZ/lhCU4/ls3SdXaNJFfJq4g/eqoO DtDgE7b1NKqaVlXjefCQUWcUgpWDsOiUwFHDsMQPa7WYDLxPPOhGb6TV4uzyjFaL0/9z 5yfXvSE4EhAlSc7NmQAXn/i1aElTo4c7awCzqrGhDAFY6FORUe0Y+ajjJ9dManuoFJ1z scng== X-Received: by 10.194.110.41 with SMTP id hx9mr18543675wjb.28.1394192789656; Fri, 07 Mar 2014 03:46:29 -0800 (PST) Received: from wifi-auth-188233.inria.fr (wifi-auth-188233.inria.fr. [128.93.188.233]) by mx.google.com with ESMTPSA id f7sm8330136wjb.7.2014.03.07.03.46.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Mar 2014 03:46:27 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_BC27D764-5449-4D7F-B153-B2A017A14044" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Karthikeyan Bhargavan In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7372387C72@uxcn10-6.UoA.auckland.ac.nz> Date: Fri, 7 Mar 2014 12:46:25 +0100 Message-Id: <5092EF89-E9F8-43C5-89B8-5A56174C7947@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C7372387C72@uxcn10-6.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mL_AtCwobc72HaBT61U80daNPE0 Cc: "" Subject: Re: [TLS] DH parameters, primality X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 11:46:36 -0000 --Apple-Mail=_BC27D764-5449-4D7F-B153-B2A017A14044 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It=92s worth rethinking TLS's DH representation for another reason. It does not currently provide a slot for the subgroup size =93q=94. This makes it impossible for the client to perform public key = validation for anything other than Sophie-Germain primes. (For suggested = validation rules see: http://tools.ietf.org/html/rfc6989#section-2.2) We exploit this problem as well in a variation of the triple handshake = attack. -K. On 07 Mar 2014, at 12:30, Peter Gutmann = wrote: > Tanja Lange writes: >=20 >> More constructively though, verifying primality given a certificate = is much >> faster=20 >=20 > A quick fix for TLS would be to switch from the current PKCS #3-style = DH > representation to FIPS 186-style, for which you can verify the = parameters > using Kravitz' kosherizer. This was proposed some time ago but didn't = get > much too much acceptance, maybe it's time to revisit it... >=20 > Peter. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_BC27D764-5449-4D7F-B153-B2A017A14044 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 It=92s = worth rethinking TLS's DH representation for another reason.
It does = not currently provide a slot for the subgroup size = =93q=94.

This makes it impossible for the = client to perform public key  validation for anything other than = Sophie-Germain primes. (For suggested validation rules see: http://tools.ietf.= org/html/rfc6989#section-2.2)

We exploit = this problem as well in a variation of the triple handshake = attack.
-K.

On 07 Mar 2014, at 12:30, = Peter Gutmann <pgut001@cs.auckland.ac.nz>= ; wrote:

Tanja Lange <tanja@hyperelliptic.org> = writes:

More constructively though, = verifying primality given a certificate is much
faster =

A quick fix for TLS would be to switch from the = current PKCS #3-style DH
representation to FIPS 186-style, for which = you can verify the parameters
using Kravitz' kosherizer.  This = was proposed some time ago but didn't get
much too much acceptance, = maybe it's time to revisit = it...

Peter.

_______________________________________________=
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mail= man/listinfo/tls

= --Apple-Mail=_BC27D764-5449-4D7F-B153-B2A017A14044-- From nobody Fri Mar 7 03:50:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F1E1A0205 for ; Fri, 7 Mar 2014 03:50:56 -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 bSSGFQYvDIG4 for ; Fri, 7 Mar 2014 03:50:54 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D304D1A01EF for ; Fri, 7 Mar 2014 03:50:53 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id hr17so2684796lab.5 for ; Fri, 07 Mar 2014 03:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isaacchua.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8SPcISdD6PyQosg6ETmBL78nkme97jF++T5dV8wvxbc=; b=RyikUdZAtSznJGP5EfeVEi5zqmBtfJ3xl32KEqaJOi1XnQClLtDRIL3acyU7GHDxQX GdmmZsBomz+xXhdwDmHjF7z/0xLSZQBbgsTwJZCEuo+Fyz5/5kHGNMbB/ACO7vPVLdxQ Lbktxl8qRLWgDhFx3MKe7ekc2ZgmzEQvioR5g= 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=8SPcISdD6PyQosg6ETmBL78nkme97jF++T5dV8wvxbc=; b=iLuAw/0Yp9CIdzQnBRKpOIMvf33jp81CWnsrDpy99sgq71TKyMOyVtcm4rsHzBuY4U hbp7frUFnCkkKUnv2Mm5BtUHHJGORjEd2jwgfklxQez2txsNujetCi0dC27ILiIwzYcN gxBDiqP6quFxZhOYeLAoU+J5/boBQPYaSrQ5QmcRf4kgk87L0sAQxtillVYm27VwSK0H v8DUlVvENVWmfJFcGfyi9ZwLrZB1ajD0aR62gMGoQK+nvhC8kcdcg6JT+mE0U4ubfrOy Q8OaTdZyEmx4+6LyA7UEEJVaERUfNAIXhmaNTyvjU4DngMbaprNT0tSnuv2eLH4H3jMZ yZPQ== X-Gm-Message-State: ALoCoQkMXOTldj7tGNuM77d1TagYWT9DcyVdTinR1Sw7DAJ1fKTCjf3/4sQy+FswwBK9hbqZ90kS MIME-Version: 1.0 X-Received: by 10.112.139.134 with SMTP id qy6mr110684lbb.66.1394193049010; Fri, 07 Mar 2014 03:50:49 -0800 (PST) Received: by 10.114.2.68 with HTTP; Fri, 7 Mar 2014 03:50:48 -0800 (PST) X-Originating-IP: [119.56.122.53] Received: by 10.114.2.68 with HTTP; Fri, 7 Mar 2014 03:50:48 -0800 (PST) In-Reply-To: <20140307110128.GA18506@LK-Perkele-VII> References: <20140307103027.GB16889@LK-Perkele-VII> <5319A206.60906@gmail.com> <20140307110128.GA18506@LK-Perkele-VII> Date: Fri, 7 Mar 2014 19:50:48 +0800 Message-ID: From: Isaac Chua To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11c344206f5d7104f402dd4f Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z7j6T8VzMObsr82B8a544Vd97Zs Cc: tls@ietf.org, Joseph Birr-Pixton Subject: Re: [TLS] DH parameters, primality X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 11:50:56 -0000 --001a11c344206f5d7104f402dd4f Content-Type: text/plain; charset=UTF-8 Generally when we talk about primes for Diffie-Hellman, we look at a sufficiently large prime (1024-4096 bit as mentioned), with also a sufficiently large subgroup order (256 bits for instance). There are two basic classes of attacks: index calculus and its derivatives, and Pollig-Hellman. The former, crudely speaking, is countered by a large enough prime modulus, and the latter a large enough subgroup order (its running time is sqrt(n) so you'd choose 256 bits for 128-bit security). It has been suggested that safe primes be used (p = 2q + 1 where q is prime), but Schnorr groups (p = qr + 1 where q is prime) were presented in NIST publications and eventually included in RFCs such as 5114. q, in such a construction determines the subgroup size, hence a safe prime by definition would have a subgroup size almost as large as the prime itself which isn't necessary. FIPS 186-4 specifies in appendix A several methods for generating and verifying DH parameters, perhaps that's a good place to start. Isaac Sent from my mobile device On Fri, Mar 07, 2014 at 12:40:06PM +0200, Yaron Sheffer wrote: > I'm far from an expert, but I seem to remember there are "pseudo > primes" that will appear as prime to any Miller-Rabin test. I don't > know how feasible it is for an attacker to generate such numbers. There are such pseudoprimes for Fermat test but not Miller-Rabin. Those pseudoprimes are known as "absolute pseudoprimes" or "Carmichael numbers". And then there are numbers that are primes, but are very weak as DH primes. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --001a11c344206f5d7104f402dd4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Generally when we talk about primes for Diffie-Hellman, we l= ook at a sufficiently large prime (1024-4096 bit as mentioned), with also a= sufficiently large subgroup order (256 bits for instance). There are two b= asic classes of attacks: index calculus and its derivatives, and Pollig-Hel= lman. The former, crudely speaking, is countered by a large enough prime mo= dulus, and the latter a large enough subgroup order (its running time is sq= rt(n) so you'd choose 256 bits for 128-bit security).

It has been suggested that safe primes be used (p =3D 2q + 1= where q is prime), but Schnorr groups (p =3D qr + 1 where q is prime) were= presented in NIST publications and eventually included in RFCs such as 511= 4. q, in such a construction determines the subgroup size, hence a safe pri= me by definition would have a subgroup size almost as large as the prime it= self which isn't necessary.

FIPS 186-4 specifies in appendix A several methods for gener= ating and verifying DH parameters, perhaps that's a good place to start= .

Isaac

Sent from my mobile device

On Fri, Mar 07, 2014 at 12:40= :06PM +0200, Yaron Sheffer wrote:
> I'm far from an expert, but I seem to remember there are "pse= udo
> primes" that will appear as prime to any Miller-Rabin test. I don= 't
> know how feasible it is for an attacker to generate such numbers.

There are such pseudoprimes for Fermat test but not Miller-Rabin.
Those pseudoprimes are known as "absolute pseudoprimes" or "= Carmichael
numbers".

And then there are numbers that are primes, but are very weak as
DH primes.


-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls
--001a11c344206f5d7104f402dd4f-- From nobody Fri Mar 7 04:09:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835191A01EC for ; Fri, 7 Mar 2014 04:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXj6MJHnpL4b for ; Fri, 7 Mar 2014 04:09: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 A39BF1A01E0 for ; Fri, 7 Mar 2014 04:09:20 -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=1394194157; x=1425730157; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=wfXAd2o10TrUMEjt5mPKZnyuB+nkKbXf45pBjKKqO1E=; b=o3IPIkYGRiIR1avRrCP4TDRBo4hin802hUH7XnGz4TzdLulCbXCGB+qp Cqw/WJhISSo2cjbnRTkxE+hNQMH5gqTLAbNlXjE2i4anSW9018wo6S74n 6wbrI7YHU/DIT9vAjKa0KRAzxACHBipfPE2sv04IcSSsxsiC/Xw/HyfQc E=; X-IronPort-AV: E=Sophos;i="4.97,607,1389697200"; d="scan'208";a="238090304" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Mar 2014 01:09:15 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Sat, 8 Mar 2014 01:09:14 +1300 From: Peter Gutmann To: "" , "ietf-ssh@netbsd.org" Thread-Topic: I can has SHA-1 hashes for RFC 2409/3526 MODP groups? Thread-Index: Ac85/g6s1yWJL+P+QD2gH1b9ES47kw== Date: Fri, 7 Mar 2014 12:09:14 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7372387C9E@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eSqZs03KtjKifhmltPFTqgi3GZQ Subject: Re: [TLS] I can has SHA-1 hashes for RFC 2409/3526 MODP groups? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 12:09:23 -0000 Geoffrey Keating writes:=0A= =0A= >I'd encourage you to do the derivation again: compute=0A= >=0A= >2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }=0A= >=0A= >and verify that it's prime.=0A= =0A= That assumes that (a) my calculation of that (what on earth is "{ [2^1918 p= i]=0A= + 124476 }", for example?) will be correct, and (b) my overall calculations= =0A= will also be correct, which is more or less the thing I'm trying to avoid: = I'd=0A= like an independent check on the values so that if I've messed up anywhere,= I=0A= can detect it. Getting a hash of the byte string seems to be the easiest w= ay=0A= to do this.=0A= =0A= Speaking of doing the derivation again, do we know if anyone's actually tri= ed=0A= to reproduce the values given in the RFC? I'm assuming it came from someth= ing=0A= like Mathematica which I don't have directly available, and Mathics gives m= e,=0A= for '2^2048 - 2^1984 - 1 + 2^64 * ((2^1918 * pi) + 124476)' the not terribl= y=0A= helpful:=0A= =0A= 323170060713110072989629682791328204232235930243637964344400413166715435658= 73=0A= 440916351244591771371847086149164662580591029693953927426555290878070964232= 927=0A= 695481445976665844136502242593753417365574610202650424305468123288740527986= 069=0A= 345182600707793335155055488870009358517077286832777252562865057729531709228= 943=0A= 077561263607903104272439999956067085492978564938102680241320640398099496994= 465=0A= 906209396510474094085543397979368739086794572799533369234200999216018730602= 022=0A= 705374745273152831923492968543993770580612325275982255795197317429444934474= 851=0A= 545487458964741061916562950289834595688065052813922041488166690320547839+18= 446=0A= 744073709551616(124476+2374278629519728535136746592397124249767311765867127= 918=0A= 570023908264629157167400846877644685208027625404323721209699497484526969413= 701=0A= 467981853825962047983251924686564710804944458674372390943883621415233322481= 794=0A= 551936525204552984042331894647861447774178735086820277226677386425466403176= 594=0A= 780063984777699548807262435341787904726367875755303786443248143665183526702= 686=0A= 263900917281336138003954386069156827670111514514969010644898285176470534075= 324=0A= 491432175331619907825556678522705737282121499935633499250184851491021463412= 446=0A= 9728944541006176128457062647724487151147320327110918144pi)=0A= =0A= which if fed to bc as:=0A= =0A= 323170060713110072989629682791328204232235930243637964344400413166715435658= 73=0A= 440916351244591771371847086149164662580591029693953927426555290878070964232= 927=0A= 695481445976665844136502242593753417365574610202650424305468123288740527986= 069=0A= 345182600707793335155055488870009358517077286832777252562865057729531709228= 943=0A= 077561263607903104272439999956067085492978564938102680241320640398099496994= 465=0A= 906209396510474094085543397979368739086794572799533369234200999216018730602= 022=0A= 705374745273152831923492968543993770580612325275982255795197317429444934474= 851=0A= 545487458964741061916562950289834595688065052813922041488166690320547839+18= 446=0A= 744073709551616*(124476+237427862951972853513674659239712424976731176586712= 791=0A= 857002390826462915716740084687764468520802762540432372120969949748452696941= 370=0A= 146798185382596204798325192468656471080494445867437239094388362141523332248= 179=0A= 455193652520455298404233189464786144777417873508682027722667738642546640317= 659=0A= 478006398477769954880726243534178790472636787575530378644324814366518352670= 268=0A= 626390091728133613800395438606915682767011151451496901064489828517647053407= 532=0A= 449143217533161990782555667852270573728212149993563349925018485149102146341= 244=0A= 69728944541006176128457062647724487151147320327110918144*pi)=0A= =0A= is reported to be:=0A= =0A= 323170060713110072989629682791328204232235930243637964344400413166715435658= 734=0A= 409163512445917713718470861491646625805910296939539274265552908780709642329= 276=0A= 954814459766658441365022425937534173655746102026504243054681232887405279860= 693=0A= 451826007077933351550554888700093585170772868327772525628650577295317092289= 430=0A= 775612636079031042724399999560670854929785649381026802413206403980994969944= 659=0A= 062093965104740940855433979793687390867945727995333692342009992160187306020= 227=0A= 053747452731528319234929685439937705806123252759822557951973174294449344748= 515=0A= 45487458964741061916562950289834595688065052816218218403485760467501055=0A= =0A= which is:=0A= =0A= 0xffffffffffffffff000000000000000000000000000000000000000000000000000000000= 000=0A= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000=0A= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000=0A= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000=0A= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000=0A= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000=0A= 00000000000000000000000001e63bffffffffffffffff=0A= =0A= which isn't right.=0A= =0A= Peter.= From nobody Fri Mar 7 04:13:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6D91A020E for ; Fri, 7 Mar 2014 04:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3EQfuDd28VL for ; Fri, 7 Mar 2014 04:13:08 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7CA1A01F5 for ; Fri, 7 Mar 2014 04:13:07 -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=1394194385; x=1425730385; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=C0ISA83fEuplQkCDyzxZwERgrulljvtCHfhVmHgZEdo=; b=l8JDogjabyg7xXDCCgXRaiSNUX/QhYfNvP2G62sjpPAPN7ciQ94LXo5S 4fn1kfOxXBesBdHV1BH5K7TgMDerbot+E+f5pzlxx5mgkSyert0qSuV9e fQy3XiPqugXIP7Q6XZ3Fyspqh8wbrkZtOq1tGsYQNWzXeFpjJ04F7l9UY w=; X-IronPort-AV: E=Sophos;i="4.97,607,1389697200"; d="scan'208";a="238090496" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Mar 2014 01:13:03 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Sat, 8 Mar 2014 01:13:03 +1300 From: Peter Gutmann To: "" , "ietf-ssh@netbsd.org" Thread-Topic: I can has SHA-1 hashes for RFC 2409/3526 MODP groups? Thread-Index: Ac85/pZtcjNXgQKnRyqzj14Zyiee9A== Date: Fri, 7 Mar 2014 12:13:02 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7372387CAB@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OcFrwvtwItC9esVthNpiFDDM4JE Subject: Re: [TLS] I can has SHA-1 hashes for RFC 2409/3526 MODP groups? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 12:13:10 -0000 =3D?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?=3D writes:=0A= =0A= >I have generated the primes 1024, 2048, 3072, 4096, 6144 and 8192 from the= =0A= >formulae and verified that:=0A= >=0A= >a: The numbers match the numbers in the RFCs.=0A= >b: The numbers are safe primes (using both Miller-Rabin tests and Lucas te= sts=0A= >on q =3D (p-1)/2, and then the Pocklington Criterion on p).=0A= >c: The small constant k is indeed the least positive integer such that the= =0A= >number is a safe prime. (Well, to be honest I am still running this test f= or=0A= >the largest group, just make sure once more.)=0A= =0A= Ah, OK, thanks. So we've got independent verification :-).=0A= =0A= Peter.= From nobody Fri Mar 7 04:20:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9238E1A021E for ; Fri, 7 Mar 2014 04:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBBtV5zE5ljI for ; Fri, 7 Mar 2014 04:20:51 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 96EB61A0243 for ; Fri, 7 Mar 2014 04:20:50 -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=1394194847; x=1425730847; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=t5jykVwys8WkeRIKGKZFtcDpkdlNuJR1AKEisOAyV1o=; b=KVuPywLDgJV1EQDetCCsKuRWKVOPOp7rivF6340wvGqvIX0SapvfEJso 2x96UZ8NpCezM2N95GAu1WniFP/2V33bu6F+oSEE//VJ8J6LHUUN2cW+4 kbzTE6PC3EAzTV+RLzeoQPRAWmt8lgcO3nPFAI0T+DQU4Tx+j67Sn2Z9F M=; X-IronPort-AV: E=Sophos;i="4.97,607,1389697200"; d="scan'208";a="238090797" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Mar 2014 01:20:46 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Sat, 8 Mar 2014 01:20:45 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] DH parameters, primality Thread-Index: Ac85/6pzkeRC8kWMQsaif6qvJ+Bl5Q== Date: Fri, 7 Mar 2014 12:20:45 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7372387CF1@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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KkVbvbdAZ5Hs2JhR-Z-MSxQl50M Subject: Re: [TLS] DH parameters, primality X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 12:20:53 -0000 Karthikeyan Bhargavan writes:=0A= =0A= >It=92s worth rethinking TLS's DH representation for another reason. It doe= s not=0A= >currently provide a slot for the subgroup size =93q=94.=0A= =0A= Yup, that's what I meant with going to the FIPS 186 representation. One of= f-=0A= the-top-of-my-head way to do this would be via an extension in the handshak= e=0A= saying "use FIPS-186 form instead of PKCS #3 form for DH values".=0A= =0A= (We really need some sort of bitflag-style extension to indicate all of the= =0A= things that are currently being done via individual TLS extensions, since= =0A= there seem to be quite a few I-can-do-better-than-the-default style indicat= ors=0A= needed for various things).=0A= =0A= Peter.= From nobody Fri Mar 7 04:27:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061611A0260 for ; Fri, 7 Mar 2014 04:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 iuYYWkClHFuW for ; Fri, 7 Mar 2014 04:27:36 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3447D1A01EC for ; Fri, 7 Mar 2014 04:27:36 -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 s27CRQB0006343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Mar 2014 07:27:26 -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 s27CRNdj006895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 7 Mar 2014 07:27:25 -0500 Message-ID: <1394195243.25354.46.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Hanno =?ISO-8859-1?Q?B=F6ck?= Date: Fri, 07 Mar 2014 13:27:23 +0100 In-Reply-To: <20140307104513.545b3c33@hboeck.de> References: <20140307104513.545b3c33@hboeck.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gFNWjZPipKXjSaDPStOE9GmrYfs Cc: tls@ietf.org Subject: Re: [TLS] DH parameters, primality X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 12:27:39 -0000 On Fri, 2014-03-07 at 10:45 +0100, Hanno Böck wrote: > Hello, > Recently two issues brought DH parameters to my attention. First, it > was mentioned in the triple handshake issue that a server sending > malicious DH parameters could cause trouble. And second a crash in > chrome was detected when using it with very short DH parameters. > > So I did some tests on that you might be interested in: > https://dh.tlsfun.de/ > > I wrote up a bit about my findings here: > http://blog.hboeck.de/archives/841-Diffie-Hellman-and-TLS-with-nonsense-parameters.html Note that the prime number along with the public key and the generator are signed by the server in the ServerKeyExchange message. If we disregard some previous problems found with that signature, the client has no reason not to believe that the server sent a valid prime. Nevertheless, even if you add a primality check there, there is no way with the parameters that are provided by TLS to check whether the prime is not of some special form that makes the DL problem easy. Moreover, there is also no way to verify that g is an actual generator, and is not an element with a small order (try sending one as g). Thus no matter how many checks you add there, they will consume time, and they will not be sufficient; in the end you'll have to rely on the server signature and that's what current implementations do. regards, Nikos From nobody Fri Mar 7 17:21:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488821A0323 for ; Fri, 7 Mar 2014 17:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j81QdE1qnux1 for ; Fri, 7 Mar 2014 17:21:28 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 60EF71A02FB for ; Fri, 7 Mar 2014 17:21:26 -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=1394241684; x=1425777684; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=a6ZyYuNSrJPvS2spYarfHnqY6GRfTTpjsMyk90tj8Rw=; b=fZOSgND5c/WNuagir/ebvTfR7pWplWXPa+nXM48gKrEimMpzlwniiVf3 FPCwB49SegdeqQg2387OG5wkJ4q/8PEdYJH5B54YbrkEFN+g3tpGn9EV+ EEjAyNGkmZocOnKHE95YWhuYIXPkfndQg6PIiKCsRYeDX59XTw5wYV47r Q=; X-IronPort-AV: E=Sophos;i="4.97,611,1389697200"; d="scan'208";a="238152508" 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; 08 Mar 2014 14:21:22 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.03.0174.001; Sat, 8 Mar 2014 14:21:21 +1300 From: Peter Gutmann To: "tls@ietf.org" , "ietf-ssh@NetBSD.org" Thread-Topic: I can has SHA-1 hashes for RFC 2409/3526 MODP groups? Thread-Index: Ac86bLZXNVJsR7G6T9eCT9gPxa4M7A== Date: Sat, 8 Mar 2014 01:21:20 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7372388364@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LIsruJzs_QlosdNtodrBSKZaKfQ Subject: Re: [TLS] I can has SHA-1 hashes for RFC 2409/3526 MODP groups? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2014 01:21:30 -0000 Mouse writes:=0A= =0A= >> Getting a hash of the byte string seems to be the easiest way to do=0A= >> this.=0A= >=0A= >Not just computing it and comparing it against the value in RFC3526?=0A= =0A= It depends what you're trying to verify. If the question is "are the value= s=0A= given in RFC 2409/3526 correct?" then that's the way to do it (and thanks f= or=0A= pointing out the issue with bc and pi :-). If the question is "does the by= te=0A= string I currently have in memory correspond to the data in the RFC" then= =0A= shelling out to Mathematica and bc isn't really an option, a SHA-1 hash for= =0A= quick verification seems the best way to go.=0A= =0A= Peter.=0A= From nobody Sat Mar 8 02:06:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D1D1A0316 for ; Fri, 7 Mar 2014 15:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, RP_MATCHES_RCVD=-0.547] 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 nQXaXWkW3-YH for ; Fri, 7 Mar 2014 15:18:59 -0800 (PST) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1C81E1A0317 for ; Fri, 7 Mar 2014 15:18:59 -0800 (PST) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id SAA28740; Fri, 7 Mar 2014 18:18:11 -0500 (EST) Date: Fri, 7 Mar 2014 18:18:11 -0500 (EST) From: Mouse Message-Id: <201403072318.SAA28740@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 7 Mar 2014 17:20:47 -0500 (EST) To: tls@ietf.org, ietf-ssh@NetBSD.org In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7372387C9E@uxcn10-6.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C7372387C9E@uxcn10-6.UoA.auckland.ac.nz> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gXbxJlXSSQg5nP-qxl_mxPRGWHg X-Mailman-Approved-At: Sat, 08 Mar 2014 02:06:01 -0800 Subject: Re: [TLS] I can has SHA-1 hashes for RFC 2409/3526 MODP groups? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Mar 2014 23:19:01 -0000 >> I'd encourage you to do the derivation again: compute >> 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 } >> and verify that it's prime. Or, at least, that it's probably prime. > That assumes that (a) my calculation of that (what on earth is "{ > [2^1918 pi] + 124476 }", for example?) Take pi, multiply by the 1918th power of two, discard the fractional part, and add 124476. Or, at least, that's what I'd read it as. This means computing pi to nearly two thousand bits of precision (or finding a reference value you trust enough), but that's really the only hard part. > will be correct, and (b) my overall calculations will also be > correct, which is more or less the thing I'm trying to avoid: I'd > like an independent check on the values so that if I've messed up > anywhere, I can detect it. Well, if you get the same thing the RFC specifies, that's reasonable confirmation you've done the calculation correctly. > Getting a hash of the byte string seems to be the easiest way to do > this. Not just computing it and comparing it against the value in RFC3526? > Speaking of doing the derivation again, do we know if anyone's > actually tried to reproduce the values given in the RFC? I'm > assuming it came from something like Mathematica which I don't have > directly available, and Mathics gives me, for '2^2048 - 2^1984 - 1 + > 2^64 * ((2^1918 * pi) + 124476)' the not terribly helpful: Few general-purpose calculator programs will actually compute pi to the necessary number of places. I know of someone who tried such a thing and got a wrong result which turned out to match the value resulting from using the irrational number in question (pi, sqrt(2), whatever it was) truncated to IEEE double precision. > [...] > which if fed to bc as: > [...]+[...]*(124476+[...]*pi) > is reported to be: > [...] > which is: > 0xffffffffffffffff000000000000000000000000000000000000000 > 000 > 000000000000000000000000000000000000000000000000000000000000000000000000000000 > 000000000000000000000000000000000000000000000000000000000000000000000000000000 > 000000000000000000000000000000000000000000000000000000000000000000000000000000 > 000000000000000000000000000000000000000000000000000000000000000000000000000000 > 000000000000000000000000000000000000000000000000000000000000000000000000000000 > 00000000000000000000000001e63bffffffffffffffff > which isn't right. However, if you add 18 more 0s to the long string of them (which the formatting makes it look likely got dropped in whatever produced the weird line breaks above - if I add 18 more 0s and paste the first two lines together, the result is exactly as long as the next five lines), that _is_ 2^2048 - 2^1984 - 1 + (2^64 * 124476). That is, it's what you get if you take pi to be 0. I suspect your bc didn't recognize the character string "pi" and treated it as an unset variable or some such, effectively replacing it with 0. I have a calculator program capable of working with numbers of this size. I told it to compute pi in hex to 500 places; truncating the result to 1918 fraction bits gives (still in hex, linebreaks added for email consumption) 3.243f6a8885a308d313198a2e03707344a4093822299f31d0082efa98ec4e6c 89452821e638d01377be5466cf34e90c6cc0ac29b7c97c50dd3f84d5b5b54709 179216d5d98979fb1bd1310ba698dfb5ac2ffd72dbd01adfb7b8e1afed6a267e 96ba7c9045f12c7f9924a19947b3916cf70801f2e2858efc16636920d871574e 69a458fea3f4933d7e0d95748f728eb658718bcd5882154aee7b54a41dc25a59 b59c30d5392af26013c5d1b023286085f0ca417918b8db38ef8e79dcb0603a18 0e6c9e0e8bb01e8a3ed71577c1bd314b2778af2fda55605c60e65525f3aa55ab 945748986263e8144055ca396a2aab10b4 Setting pi to this value and telling it to compute (still working in hex, hence the #d prefixes all over and the cvt() call because it doesn't like mixed-base arithmetic) pow(2,#d2048)-pow(2,#d1984)-1+(pow(2,#d64)*((pi*pow(2,#d1918))+cvt(#d124476,#d16))) I get (again, line breaks added for email) ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74 020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f1437 4fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7ed ee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf05 98da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb 9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3b e39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf695581718 3995497cea956ae515d2261898fa051015728e5a8aacaa68ffffffffffffffff which is the value in RFC3526 (after case conversion and whitespace fixup, the two text strings are identical). I haven't done anything about checking it for primality. If anyone would like to look at the calculator program in question, git clone git://git.rodents-montreal.org/Mouse/calc and look at calc.c. It might even build for you, though not with the Makefile from the git repo unless you pick up ftp.rodents-montreal.org:/mouse/local/src/makefiles/makefiles-20100906/local-prog and maybe not even then. (icalc.c is ignorable - known broken.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From nobody Sat Mar 8 02:21:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608241A015B for ; Sat, 8 Mar 2014 02:21:50 -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, 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 d_gzw8Wn8Glk for ; Sat, 8 Mar 2014 02:21:48 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBCA1A01B5 for ; Sat, 8 Mar 2014 02:21:48 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 130A51C2151; Sat, 8 Mar 2014 11:21:43 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id C72091FE018E; Sat, 8 Mar 2014 11:21:42 +0100 (CET) Date: Sat, 8 Mar 2014 11:21:42 +0100 From: Kurt Roeckx To: Mouse Message-ID: <20140308102142.GA25856@roeckx.be> References: <9A043F3CF02CD34C8E74AC1594475C7372387C9E@uxcn10-6.UoA.auckland.ac.nz> <201403072318.SAA28740@Chip.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201403072318.SAA28740@Chip.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bUcvB_rMJDNRACoSiY6f4fYrKAc Cc: ietf-ssh@NetBSD.org, tls@ietf.org Subject: Re: [TLS] I can has SHA-1 hashes for RFC 2409/3526 MODP groups? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2014 10:21:50 -0000 On Fri, Mar 07, 2014 at 06:18:11PM -0500, Mouse wrote: > > However, if you add 18 more 0s to the long string of them (which the > formatting makes it look likely got dropped in whatever produced the > weird line breaks above - if I add 18 more 0s and paste the first two > lines together, the result is exactly as long as the next five lines), > that _is_ 2^2048 - 2^1984 - 1 + (2^64 * 124476). That is, it's what > you get if you take pi to be 0. I suspect your bc didn't recognize the > character string "pi" and treated it as an unset variable or some such, > effectively replacing it with 0. If you want pi in bc, you need to start bc with the -l option and do: pi=4*a(1) Kurt From nobody Sat Mar 8 02:29:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D679A1A0265 for ; Sat, 8 Mar 2014 02:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.996 X-Spam-Level: * X-Spam-Status: No, score=1.996 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 WvfSfeowHMdN for ; Sat, 8 Mar 2014 02:29:43 -0800 (PST) Received: from vsp1.ballou.se (vsp1.ballou.se [91.189.40.82]) by ietfa.amsl.com (Postfix) with SMTP id A8CC61A015B for ; Sat, 8 Mar 2014 02:29:41 -0800 (PST) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp1.ballou.se (Halon Mail Gateway) with ESMTP; Sat, 8 Mar 2014 11:27:32 +0100 (CET) Received: from [192.168.0.10] (s83-191-225-212.cust.tele2.se [83.191.225.212]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id C20FB1E0A6; Sat, 8 Mar 2014 11:29:34 +0100 (CET) Message-ID: <531AF11B.3050106@streamsec.se> Date: Sat, 08 Mar 2014 11:29:47 +0100 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Peter Gutmann , "tls@ietf.org" , "ietf-ssh@NetBSD.org" References: <9A043F3CF02CD34C8E74AC1594475C7372388364@uxcn10-6.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7372388364@uxcn10-6.UoA.auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/78yTf8uQiZOVWAFfIDIGyeM_qxY Subject: Re: [TLS] I can has SHA-1 hashes for RFC 2409/3526 MODP groups? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2014 10:29:45 -0000 Peter Gutmann skrev 2014-03-08 02:21: > Mouse writes: > >>> Getting a hash of the byte string seems to be the easiest way to do >>> this. >> Not just computing it and comparing it against the value in RFC3526? > It depends what you're trying to verify. If the question is "are the values > given in RFC 2409/3526 correct?" then that's the way to do it (and thanks for > pointing out the issue with bc and pi :-). If the question is "does the byte > string I currently have in memory correspond to the data in the RFC" then > shelling out to Mathematica and bc isn't really an option, a SHA-1 hash for > quick verification seems the best way to go. The problem with calculating the hash of the internal representation, is that the hash will depend on the internal representation, which is prone to be implementation specific. Is it little endian or big endian? Is there a zero valued word in the most significant position or not? I think it is possible to run a relatively fast arithmetic test that will be dominated by the time it takes to perform a single modular exponentiation. If you got a big num libary, implementing an optimized formula for pi is relatively easy. You could implement a function that returns the prime p given the bit size n and small constant k, and let this function verify that k is the correct value. From nobody Sat Mar 8 03:57:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2BF1A01E1 for ; Sat, 8 Mar 2014 03:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tN9xTLL61k5 for ; Sat, 8 Mar 2014 03:57:16 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 5306F1A011E for ; Sat, 8 Mar 2014 03:57:16 -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=1394279832; x=1425815832; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=yh3WVrUMyIOG/gUbqebvzdKUD3ImZPNjFff8LZ2uV2U=; b=lyWzBNHabfWHwc/wDlQJlxDyDFp1XoaqOBp4W21PZX7qwELxJrlvPkU4 hrbcQ0e0xa8cTRVjbgjbdFC23vSRZlOMVt1eSUQzD+GbvPTfE3jd4aUvQ Q8fie3QZh/Ro084sOXOzNYPys0GD6K/Dlz0EYI00SEaz3w15dIMOrvRor M=; X-IronPort-AV: E=Sophos;i="4.97,614,1389697200"; d="scan'208";a="238194824" 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; 09 Mar 2014 00:57:11 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sun, 9 Mar 2014 00:57:10 +1300 From: Peter Gutmann To: "" , "ietf-ssh@netbsd.org" Thread-Topic: I can has SHA-1 hashes for RFC 2409/3526 MODP groups? Thread-Index: Ac86xYl2EiFF8LNqSgSEq6nmX+5ISg== Date: Sat, 8 Mar 2014 11:57:10 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7372388540@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zsAuYqK2jR2B4xIjadyZ-YJ_2cE Subject: Re: [TLS] I can has SHA-1 hashes for RFC 2409/3526 MODP groups? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2014 11:57:19 -0000 Henrick Hellstr=F6m writes:=0A= =0A= >The problem with calculating the hash of the internal representation, is t= hat=0A= >the hash will depend on the internal representation, which is prone to be= =0A= >implementation specific. Is it little endian or big endian? Is there a zer= o=0A= >valued word in the most significant position or not?=0A= =0A= I don't need the hash of the internal representation (my code does its own= =0A= integrity checking, so once it's in the internal form it's protected, at le= ast=0A= from random corruption), just of the byte-string representation of p as=0A= stored/as present in the RFC. So for example for the 2048-bit MODP group i= t'd=0A= be the SHA-1 hash of, in C notation, { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,= =0A= 0xFF, 0xFF, 0xC9, 0x0F, 0xDA, 0xA2, ... 0xFF }.=0A= =0A= Peter.=0A= =0A= From nobody Sat Mar 8 04:05:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189881A0265 for ; Sat, 8 Mar 2014 04:05:35 -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 sVQYcDSh-VjL for ; Sat, 8 Mar 2014 04:05:33 -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 773311A025C for ; Sat, 8 Mar 2014 04:05:33 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id p61so6464876wes.27 for ; Sat, 08 Mar 2014 04:05:28 -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=UuyKaTbq9lu9t/KMqBYUW9rOuHwBLTwuZYczFkjNLDs=; b=zlPivLtIOeY4mYWCYq2vmj6LcGdOLdaaB0uvEw1RGhf5UDKMvnKcehl9UyvF5hwYtn BhGdEYiRTzFYh7owXpLSjeUL1w5xDY/MlpSDrJxBZ6hwhiObbLGzuPRnEctesNmzJEeK ejAZGNDG09SSW4U8qwj8YCvO6Dt4q14X1gE10PTF1ECstQzW9KGxqvnTZuutHxPIHUgO k80Ic1CeOMHyY4wtVqpfFeua3RK6NA2tnVi70pgslKlhBY7O16hw9UwqS70wIfZ80Qb3 /rqxPf0Qt3KG+7sSdWJoOjwtpv22gpMV0gpnXjKWr/e2Ho3ScxJd1EeJdPa7qbIaEjPX sSRA== MIME-Version: 1.0 X-Received: by 10.194.78.77 with SMTP id z13mr198970wjw.64.1394280328448; Sat, 08 Mar 2014 04:05:28 -0800 (PST) Received: by 10.227.10.196 with HTTP; Sat, 8 Mar 2014 04:05:28 -0800 (PST) Date: Sat, 8 Mar 2014 12:05:28 +0000 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6vOyBFsAxnnRdv7qEr-Joe2KVyc Subject: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2014 12:05:35 -0000 It seems like the main use case for renegotiation is client authentication. For two reasons: 1. a need for client authentication is often discovered in the middle of a session 2. renegotiation provides confidentiality protection for the client certificate I think that main user of this feature is HTTP. If we are to get rid of renegotiation (and we intend to for HTTP/2 if at all possible), then we need some way to address these concerns. It turns out that the main reason renegotiation causes issues is that it can happen mid-stream, when you have the possibility for confusion about the security properties of application data, particularly when protocol atoms span the pair of ChangeCipherSpec messages associated with the renegotiation. A current proposal in HTTP/2 is to forbid renegotiation, except at the very beginning of a connection, and only for client authentication. (In TLS 1.3, we protect the client certificate, so the renegotiation isn't needed at all.) That addresses point 2. We plan to have something in HTTP that causes a client to make a new, client-authenticated connection, so that we can address point 1. This results in a small problem. In TLS, a server decides to request client authentication. On a new connection, there is no context available at the server to decide to request that the client offer a cert. I've submitted a draft that describes a solution for this small part of the problem. Here: http://datatracker.ietf.org/doc/draft-thomson-tls-care/ From nobody Sat Mar 8 08:21:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967881A029C for ; Sat, 8 Mar 2014 08:21:07 -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 Tn9F3wJydXvW for ; Sat, 8 Mar 2014 08:21:04 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43F291A02B5 for ; Sat, 8 Mar 2014 08:21:03 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 392002C9F8; Sat, 8 Mar 2014 08:20:59 -0800 (PST) From: "Jim Schaad" To: "'Martin Thomson'" , References: In-Reply-To: Date: Sat, 8 Mar 2014 08:19:12 -0800 Message-ID: <004a01cf3aea$2505d050$6f1170f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIzaWQ3lVk6xys+lf7WyeRAXDQtx5oPAUrQ Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/tls/B5ptzBCfvSWtH58IZQVnCKuu7Gg Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2014 16:21:07 -0000 There is a major requirement for renegotiation for protection of the client credentials that is being used in various EAP methods as well. HTTP is not the only use of this. Jim > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Saturday, March 08, 2014 4:05 AM > To: tls@ietf.org > Subject: [TLS] Renegotiation and client authentication > > It seems like the main use case for renegotiation is client authentication. For > two reasons: > > 1. a need for client authentication is often discovered in the middle of a > session > > 2. renegotiation provides confidentiality protection for the client certificate > > I think that main user of this feature is HTTP. If we are to get rid of > renegotiation (and we intend to for HTTP/2 if at all possible), then we need > some way to address these concerns. > > It turns out that the main reason renegotiation causes issues is that it can > happen mid-stream, when you have the possibility for confusion about the > security properties of application data, particularly when protocol atoms span > the pair of ChangeCipherSpec messages associated with the renegotiation. > > A current proposal in HTTP/2 is to forbid renegotiation, except at the very > beginning of a connection, and only for client authentication. > (In TLS 1.3, we protect the client certificate, so the renegotiation isn't needed > at all.) That addresses point 2. > > We plan to have something in HTTP that causes a client to make a new, client- > authenticated connection, so that we can address point 1. > > This results in a small problem. In TLS, a server decides to request client > authentication. On a new connection, there is no context available at the > server to decide to request that the client offer a cert. > > I've submitted a draft that describes a solution for this small part of the > problem. Here: > > http://datatracker.ietf.org/doc/draft-thomson-tls-care/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Mar 8 08:25:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44021A02B2 for ; Sat, 8 Mar 2014 08:25:13 -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 kbxnNasYkMNc for ; Sat, 8 Mar 2014 08:25:12 -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 01D5E1A029C for ; Sat, 8 Mar 2014 08:25:11 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id b13so440402wgh.29 for ; Sat, 08 Mar 2014 08:25:06 -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=DhEK/X4gpwFPqiq4vR86cYuYbdRfWOLYFwMifJ2VR2w=; b=zkfWrOPaBBQOlNl1xpKPSPqkptcW1i7FQjUHRUGXn7iasHVf4RMypHMnjgYMtm9Qq1 O7LFzsFmMDs05abfAnALxur6j88NFcAtQIxNxPx6wQhuw79ztvHE5i8XDjaIGQS4wJ2t kQ9ybBMbYZFAG8U4lKPRQpr99i/WeSNYacNzjkwRNqdrbOtWKJnK6A8gcTJPw0BAp6o1 eHJ4TgVuV7lE97QdH5DysUA3uYmCY0MWVHedIOcIJhCHwndeKewbO7ChIpTkaddbHChd 4zmPsJkxLgsE6FjHQkJfsmErneDXaidhIsulu3C61cre0XDCFZIFQ/Ij6gWOQ2ue6oWB zEww== MIME-Version: 1.0 X-Received: by 10.194.185.148 with SMTP id fc20mr24673653wjc.27.1394295906773; Sat, 08 Mar 2014 08:25:06 -0800 (PST) Received: by 10.227.10.196 with HTTP; Sat, 8 Mar 2014 08:25:06 -0800 (PST) In-Reply-To: <004a01cf3aea$2505d050$6f1170f0$@augustcellars.com> References: <004a01cf3aea$2505d050$6f1170f0$@augustcellars.com> Date: Sat, 8 Mar 2014 16:25:06 +0000 Message-ID: From: Martin Thomson To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q7p2ZQUJ5uysAdva6rswLI0Dy7s Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2014 16:25:14 -0000 On 8 March 2014 16:19, Jim Schaad wrote: > There is a major requirement for renegotiation for protection of the client > credentials that is being used in various EAP methods as well. HTTP is not > the only use of this. I'd be interested in learning whether a similar mechanism would suffice for you. Nonetheless, this is a decision that is being made for HTTP. Presumably EAP could continue to use renegotiation. I recommend you explain your use case for renegotiation, since it's at risk in TLS 1.3. From nobody Sat Mar 8 12:30:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214A01A012C for ; Sat, 8 Mar 2014 12:30: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 UozXIerXzeky for ; Sat, 8 Mar 2014 12:30:44 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D0AD21A00F2 for ; Sat, 8 Mar 2014 12:30:43 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id hr17so3706785lab.33 for ; Sat, 08 Mar 2014 12:30:38 -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=q5WSL0VW0AqCJgmNnibHXNXUCu8rIg9gLJ74X4PekLs=; b=sTQQeOL1KXtW5WuaH9h0YLnf8efpsWF8YY1SrGeFk59RZGB1lSF5oWc3Q94bgAlqq1 g/yrM20w/s/mc8M1uhtnb/HEgjh49WDWJ9iCgqkZ64v2xArW3Mcp4inJeRoqR2O8yaBt fDvaA8lkxG++eeFd5sKTtaCEKo+SCQkgdkz8xuS4nnflSc8/1we9pWrfDalp+LNOwX+o j8nqrrsslkEhegwxXZjPRD6eCa0E5X5d0YSEKOG31c5fwf11Q1RQuzFskPecgY64BLEl 743CxHpMfCylGpiqaxDlJVoevDvVChLZzws3iGmmr7Xp9tDQYHKEVopuqPSIJdHT5lxo Lr9g== MIME-Version: 1.0 X-Received: by 10.112.129.168 with SMTP id nx8mr2943535lbb.37.1394310638272; Sat, 08 Mar 2014 12:30:38 -0800 (PST) Sender: alangley@gmail.com Received: by 10.112.33.136 with HTTP; Sat, 8 Mar 2014 12:30:37 -0800 (PST) In-Reply-To: References: <20140306110100.5058.89585.idtracker@ietfa.amsl.com> Date: Sat, 8 Mar 2014 15:30:37 -0500 X-Google-Sender-Auth: MMhLtke3fwzR37MLF0aHwtQKEjg Message-ID: From: Adam Langley To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DQbobymIEsz0tEChGSVC3nTyVv0 Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-thomson-tls-acp-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: Sat, 08 Mar 2014 20:30:45 -0000 On Fri, Mar 7, 2014 at 4:38 AM, Martin Thomson wrote: > Just so that folks don't wonder about what this is about, there's a > thread in rtcweb@ that I've started on the topic. This extension > might be required to support some security features in WebRTC. Seems like this could be easily supported with ALPN, no? Cheers AGL From nobody Sat Mar 8 13:12:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC06E1A02DB for ; Sat, 8 Mar 2014 13:12:11 -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 2bxdgE4-mhmh for ; Sat, 8 Mar 2014 13:12:10 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id C0AA71A01C6 for ; Sat, 8 Mar 2014 13:12:09 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id l4so3776290lbv.0 for ; Sat, 08 Mar 2014 13:12:04 -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=LY6lrZXQuOchMl/ubCXn2Kx99zm7sUf7fZjgqTTlZ80=; b=HYtb/z9fX98n1uiHMGwPJGQ8uhC55Ol5NgkwGTufsl+Jf4O0Cv4Qklh5fymwZYi5Kx UWVI/+R3o90r/HmAanFcwnYjmy3QP1ZXgTHSao75KzSDDuJPa0rjmEIltufjvyZ+BmhP 7yYQZsymd3ijMTuG7V7PVe27C3+Hjaq+hTM4tcBURKc+A6TJgAo+RJxG8m3C1YTlIHoK JMEY5NN2YSn4Kl1W5CbpV7A2OYXq+7MNEO8jVSij0GwPFp1vhhnCKaME9Ev7VworkicE EVaAFJDNlJX4SsG8BwM8qj2bLsjB3o5iWH9DPWobd2N5+QskevvHXrlVb/PMT+wo/ohg SH6Q== MIME-Version: 1.0 X-Received: by 10.152.210.70 with SMTP id ms6mr17019448lac.5.1394313124331; Sat, 08 Mar 2014 13:12:04 -0800 (PST) Sender: alangley@gmail.com Received: by 10.112.33.136 with HTTP; Sat, 8 Mar 2014 13:12:04 -0800 (PST) In-Reply-To: References: Date: Sat, 8 Mar 2014 16:12:04 -0500 X-Google-Sender-Auth: JuB8paDHl5ysLVM7k8EtOPcoiz8 Message-ID: From: Adam Langley To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/62UoH-ag-mozrtPEG8clogAcOWY Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2014 21:12:12 -0000 On Sat, Mar 8, 2014 at 7:05 AM, Martin Thomson wrote: > We plan to have something in HTTP that causes a client to make a new, > client-authenticated connection, so that we can address point 1. SPDY previously had the concept of a CREDENTIAL frame - a message that contained a signature of a channel binding value. Obviously, channel bindings are a bad idea until the master-secret is fixed, but that's not a terminal problem. (HTTP/2 already requires ALPN support in the TLS stack.) The CREDENTIAL frame was dropped for complexity reasons, and it would need some kind of request message to support the use-case suggested, but it does offer the possibility of a nicer mechanism of client-auth that doesn't tie deeply into the TLS stack. Additionally, connection pooling in HTTP/2 complicates client-auth because a TLS connection can only have a single client-cert. CREDENTIAL had the client manage a logical space of possible credentials at the server. I'm not sure whether it's worth the complexity for something so rarely used, but might be worth pondering. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From nobody Sat Mar 8 23:00:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC3F1A031B for ; Sat, 8 Mar 2014 23:00:22 -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 1hc0N26mLSyG for ; Sat, 8 Mar 2014 23:00:21 -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 559601A01B6 for ; Sat, 8 Mar 2014 23:00:21 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id t61so7026477wes.2 for ; Sat, 08 Mar 2014 23:00: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=Y4mIZNJE1kmgia7wTK0+PWctLuTgpKv92jsg9r92nLk=; b=MYgkAVyojustjV/vhlZ/P+VBkpXtZqQhPCbMKHMiTaHq8Lv0SAv7DPeWvd+AfUcOdG 5uN4zbwEU7ffs2wwNHj/MxSV5fBX7LHW+LTIrhC58kzR7aQOldEULhAWzE1HQqA3KaM8 x7ul89p2Q9+9g/KcJx1cAtv+awOSwVUX04u5RFXLQM350YilS8Ge1Jeq7wI2ku26AxYV etto869fbNSu0DiKmi2cWizu/Q4KAxWPx6moJMyGJYHYA05ynZZbYQ/oTVfEK780MrTd 1usUJhkmOSj/V6/9dSXhMW2VQQTKD4J16UDb1EMv9Czen5yQs9EdBp84X+Mi1VLSzKEC xa4Q== MIME-Version: 1.0 X-Received: by 10.194.90.196 with SMTP id by4mr82599wjb.45.1394348415887; Sat, 08 Mar 2014 23:00:15 -0800 (PST) Received: by 10.227.10.196 with HTTP; Sat, 8 Mar 2014 23:00:15 -0800 (PST) In-Reply-To: References: <20140306110100.5058.89585.idtracker@ietfa.amsl.com> Date: Sun, 9 Mar 2014 07:00:15 +0000 Message-ID: From: Martin Thomson To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/114Rk_ks98hCYj4WC3Ia8ATLC8E Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-thomson-tls-acp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 07:00:23 -0000 On 8 March 2014 20:30, Adam Langley wrote: > Seems like this could be easily supported with ALPN, no? Yes. I thought of that. You could use ALPN to signal all sorts of things. I'd prefer to avoid overloading ALPN in that way. In this case, it might be OK, but combining generic semantics into ALPN generates exponentially more tokens. Maybe it's just a reaction to suggestions of a need for structured ALPN tokens, which is a recurring theme in HTTP/2 discussions. I want to avoid getting into that situation, which means that I favour extension over an increasing reliance on ALPN. From nobody Sat Mar 8 23:46:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A791A0202 for ; Sat, 8 Mar 2014 23:46: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 z_bnPkzV0jqK for ; Sat, 8 Mar 2014 23:46:09 -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 D24DE1A0208 for ; Sat, 8 Mar 2014 23:46:08 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id t60so6998666wes.5 for ; Sat, 08 Mar 2014 23:46: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=Hoo1IsaSBOnVJakWyx/OwOo4fpBMrKsdNEC3cEKEJkw=; b=uT3FF0m/G7tz6zK23sW6+bVHnxSXIe92Phaa+j5TL258icx+15OQ1I3p8yWwYMbicy IB+EiLuAPCvDkEMpyz+uYXbc6X9trLMtAQlm1eAwj7lh1bg5WEIyIb6XJ+ZexOscfsKg JNdKT2JrnQbY1bzs3NHCYsw/VWPmS4n7jZoN5ZbTQFmO0hOx5lChW3BC/7M27wURFoCh JKf8c0Bhi/1RffM0riXzhCIN87ONZ4LJlKD1F36VylvW7pyvXshaIu0BKSPKYZJQGPTF 5g2FDSLshWx1Rm92Q06AgQvwNYhrxqJPugNivHXUSxjOkKtmAmtA+F7HSO0JCBNY5c/l 7f7Q== MIME-Version: 1.0 X-Received: by 10.180.77.129 with SMTP id s1mr3742500wiw.56.1394351163572; Sat, 08 Mar 2014 23:46:03 -0800 (PST) Received: by 10.227.10.196 with HTTP; Sat, 8 Mar 2014 23:46:03 -0800 (PST) In-Reply-To: References: Date: Sun, 9 Mar 2014 07:46:03 +0000 Message-ID: From: Martin Thomson To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/m-LEwr1hdKUDz2IXanfflQMCY0Y Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2014 07:46:11 -0000 On 8 March 2014 21:12, Adam Langley wrote: > SPDY previously had the concept of a CREDENTIAL frame - a message that > contained a signature of a channel binding value. Obviously, channel > bindings are a bad idea until the master-secret is fixed, but that's > not a terminal problem. (HTTP/2 already requires ALPN support in the > TLS stack.) Correct. Since the whole point of this exercise is to address this use case (client authentication) without relying renegotiation, I think that we are safe in saying that we can rely on the master-secret being stable. Strangely enough, the CREDENTIAL frame did come up in discussions over in HTTP-land. The reaction wasn't that positive. The perceived complexity was too great. That was the reason it was removed in the first place. There are still implementations out there that don't have RFC 5705 support, or don't want to rely on it. > Additionally, connection pooling in HTTP/2 complicates client-auth > because a TLS connection can only have a single client-cert. Part of the proposed solution here would be to strongly recommend (with MUST) that connections aren't pooled when client authentication is requested. See the HTTP part of the solution, here: http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/ --Martin p.s., I'm a little surprised that you didn't suggest ALPN for this one too, a number of other people did :) From nobody Sun Mar 9 00:33:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273811A01F9 for ; Sun, 9 Mar 2014 00:33:09 -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 R2tQxqM6GWKO for ; Sun, 9 Mar 2014 00:33:07 -0800 (PST) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDD71A017E for ; Sun, 9 Mar 2014 00:33:07 -0800 (PST) Received: by mail-yh0-f42.google.com with SMTP id a41so6073940yho.1 for ; Sun, 09 Mar 2014 00:33:02 -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=KMcdkPaZejXiwJfl9aXgNAyMZ8p39zf/d5axSS5SQBo=; b=Ao1KO9W9MmB2FNRJyzzilCpRhF84qAwcfIL5LZnp9GFutipDfnAnYPPWD0ADfWZcsv YCcVcyh+o1D4jQHK1S5GKBwUxdZ8E3xiem646GwvowORBczY9s4IVjohK46vBugWsqg5 kkF7ACdR3WfAQR6OVU8XyF8RHf5/vvgOgFDD400eCpBJv4uLuMjmXkHV1/WRPaW6we3a SgH3rqhhpgevAQFL64eg+NkIw2hH2P+SqM5n6sKzQo9INbP/UhCCK1a0VGKJThTxTT7u fBU07i3Zil8WlYVgXD3PAx2dSZLKIwU0l/fMGyT3O3BpvCeUsPBkIiqLnvQeXHnkOo7J fgGw== MIME-Version: 1.0 X-Received: by 10.236.152.233 with SMTP id d69mr35939856yhk.11.1394353982472; Sun, 09 Mar 2014 00:33:02 -0800 (PST) Received: by 10.170.80.214 with HTTP; Sun, 9 Mar 2014 00:33:02 -0800 (PST) In-Reply-To: References: <20140306110100.5058.89585.idtracker@ietfa.amsl.com> Date: Sun, 9 Mar 2014 00:33:02 -0800 Message-ID: From: Watson Ladd To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BGWcy9CeXOnDwh7PkN1J2qw2lNA Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-thomson-tls-acp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 08:33:09 -0000 On Sat, Mar 8, 2014 at 11:00 PM, Martin Thomson wrote: > On 8 March 2014 20:30, Adam Langley wrote: >> Seems like this could be easily supported with ALPN, no? > > Yes. I thought of that. You could use ALPN to signal all sorts of > things. I'd prefer to avoid overloading ALPN in that way. > > In this case, it might be OK, but combining generic semantics into > ALPN generates exponentially more tokens. Maybe it's just a reaction > to suggestions of a need for structured ALPN tokens, which is a > recurring theme in HTTP/2 discussions. I want to avoid getting into > that situation, which means that I favour extension over an increasing > reliance on ALPN. Why does this need an extension? It seems you can send it over the channel inside TLS with no trouble. Sincerely, Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Mar 9 01:41:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53CE1A0328 for ; Sun, 9 Mar 2014 01:41:07 -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 cJVZiH2KA621 for ; Sun, 9 Mar 2014 01:41:06 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6775A1A0240 for ; Sun, 9 Mar 2014 01:41:06 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id q58so7066066wes.6 for ; Sun, 09 Mar 2014 01:41:01 -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=QXRgAd5l1co/V8rsmtbMDtue2AfXxaOasviM3bmTwDI=; b=xJaXNfVQXRKGpu0yr0RUTX1jCThYmvi2afwI5gftVi5FUt3X20b8fDTczkJ8ffV5es FVRaKw7twysl6+XpXCvP134e9qxdzCWg0sXHd71GjyIJDFEvQIOSfpVzw7HP1DGNpzls 8K+lrNUd80VubE2GBUn7WEW+SBrP/e2ArhAgmScTRyFLxuEQ32wNzrBsPXSa+f8/b8hg Aop9KOQm8iPm12F21MWihHboHziQywjfQaD6ddKVFjgRNgDx2yuU7mUnkzt3vpE7e7jF fkUTluxJ+zt8Ix8HXmmxuXVgWGelRi3iwPxsJQ/2gsH5O3GvJ/p9U7oTaYlrnRKnPQpC iFcw== MIME-Version: 1.0 X-Received: by 10.180.89.211 with SMTP id bq19mr4967508wib.58.1394358061107; Sun, 09 Mar 2014 01:41:01 -0800 (PST) Received: by 10.227.10.196 with HTTP; Sun, 9 Mar 2014 01:41:01 -0800 (PST) In-Reply-To: References: <20140306110100.5058.89585.idtracker@ietfa.amsl.com> Date: Sun, 9 Mar 2014 09:41:01 +0000 Message-ID: From: Martin Thomson To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CRKozcGiKHC2RoC2USsj3bBJ4Po Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-thomson-tls-acp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 09:41:08 -0000 On 9 March 2014 08:33, Watson Ladd wrote: > Why does this need an extension? It seems you can send it over the > channel inside TLS with no trouble. The specific use case that caused me to write this draft doesn't work that way. DTLS-SRTP (RFC5764) doesn't use application data; it's just a handshake followed by extractors (RFC 5705). It is possible to use RTP header extensions to carry an indication and rely on RTCP feedback to obtain acknowledgement, but that is significantly more complex, it has new failure modes (RTP header extensions have to be negotiated and are by definition ignorable) and results in interoperability issues (RTP header extensions have been known to cause issues). From nobody Sun Mar 9 04:56:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0C71A026F for ; Sat, 8 Mar 2014 10:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hhTjAWq1eX94 for ; Sat, 8 Mar 2014 10:13:13 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF471A02D9 for ; Sat, 8 Mar 2014 10:13:12 -0800 (PST) Received: from mail217-co9-R.bigfish.com (10.236.132.239) by CO9EHSOBE036.bigfish.com (10.236.130.99) with Microsoft SMTP Server id 14.1.225.22; Sat, 8 Mar 2014 18:13:07 +0000 Received: from mail217-co9 (localhost [127.0.0.1]) by mail217-co9-R.bigfish.com (Postfix) with ESMTP id E3A41E00073; Sat, 8 Mar 2014 18:13:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.16; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zz98dIe0eah1432Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1082kzz1de098h1de097hz31h2a8h839hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1ff5h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: softfail (mail217-co9: transitioning domain of juniper.net does not designate 66.129.239.16 as permitted sender) client-ip=66.129.239.16; envelope-from=mdb@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail217-co9 (localhost.localdomain [127.0.0.1]) by mail217-co9 (MessageSwitch) id 1394302383694623_28879; Sat, 8 Mar 2014 18:13:03 +0000 (UTC) Received: from CO9EHSMHS016.bigfish.com (unknown [10.236.132.234]) by mail217-co9.bigfish.com (Postfix) with ESMTP id 9A4F01EC0047; Sat, 8 Mar 2014 18:13:03 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by CO9EHSMHS016.bigfish.com (10.236.130.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 8 Mar 2014 18:13:03 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 8 Mar 2014 10:13:02 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s28ID0V84269; Sat, 8 Mar 2014 10:13:00 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id EE8491148D; Sat, 8 Mar 2014 10:12:58 -0800 (PST) To: Kurt Roeckx , Peter Gutmann In-Reply-To: <20140308102142.GA25856@roeckx.be> References: <9A043F3CF02CD34C8E74AC1594475C7372387C9E@uxcn10-6.UoA.auckland.ac.nz> <201403072318.SAA28740@Chip.Rodents-Montreal.ORG> <20140308102142.GA25856@roeckx.be> Comments: In-reply-to: Kurt Roeckx message dated "Sat, 08 Mar 2014 11:21:42 +0100." From: "Mark D. Baushke" X-Mailer: MH-E 8.2; nmh 1.2; GNU Emacs 22.1.1 X-Face: #8D_6URD2G%vC.hzU Sender: MIME-Version: 1.0 Content-Type: text/plain X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jnyndLBu4bipZAF0gUVlbFSt67w X-Mailman-Approved-At: Sun, 09 Mar 2014 04:56:54 -0700 Cc: ietf-ssh@NetBSD.org, Mouse , tls@ietf.org Subject: Re: [TLS] I can has SHA-1 hashes for RFC 2409/3526 MODP groups? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2014 18:13:17 -0000 Hi Kurt, You raise a good point. Folks with 'bc -l' should be able to verify the MODP groups. Kurt Roeckx writes: > On Fri, Mar 07, 2014 at 06:18:11PM -0500, Mouse wrote: > > > > However, if you add 18 more 0s to the long string of them (which the > > formatting makes it look likely got dropped in whatever produced the > > weird line breaks above - if I add 18 more 0s and paste the first two > > lines together, the result is exactly as long as the next five lines), > > that _is_ 2^2048 - 2^1984 - 1 + (2^64 * 124476). That is, it's what > > you get if you take pi to be 0. I suspect your bc didn't recognize the > > character string "pi" and treated it as an unset variable or some such, > > effectively replacing it with 0. > > If you want pi in bc, you need to start bc with the -l option and do: > pi=4*a(1) Yes. Of course, to get the same values as is used in the RFCs more fractional bits need to be calculated Using bc to calculate the group14 and group15 primes: $ bc -l scale=1000 /* should be enough for group 14 and group 15 */ obase=16 /* A function to return the largest integral value not greater than x */ define floor(x) { auto s s = scale scale = 0 x /= 1 /* round x down */ scale = s return (x) } pi=4*a(1) pi 3.243F6A8885A308D313198A2E03707344A4093822299F31D0082EFA98EC4E6C8945\ 2821E638D01377BE5466CF34E90C6CC0AC29B7C97C50DD3F84D5B5B54709179216D5\ D98979FB1BD1310BA698DFB5AC2FFD72DBD01ADFB7B8E1AFED6A267E96BA7C9045F1\ 2C7F9924A19947B3916CF70801F2E2858EFC16636920D871574E69A458FEA3F4933D\ 7E0D95748F728EB658718BCD5882154AEE7B54A41DC25A59B59C30D5392AF26013C5\ D1B023286085F0CA417918B8DB38EF8E79DCB0603A180E6C9E0E8BB01E8A3ED71577\ C1BD314B2778AF2FDA55605C60E65525F3AA55AB945748986263E8144055CA396A2A\ AB10B6B4CC5C341141E8CEA15486AF7C72E993B3EE1411636FBC2A2BA9C55D741831\ F6CE5C3E169B87931EAFD6BA336C24CF5C7A325381289586773B8F48986B4BB9AFC4\ BFE81B6628219361D809CCFB21A991487CAC605DEC8032EF845D5DE98575B1DC2623\ 02EB651B8823893E81D396ACC50F6D6FF383F442392E0B4482A484200469C8F04A9E\ 1F9B5E21C66842F6E96C9A670C9C61ABD388F06A51A0D2D8542F68960FA728AB5133\ A36EEF0B6C137A3B8 2^2048 - 2^1984 - 1 + 2^64 * (floor(pi * 2^1918) + 124476) /* group 14 */ FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E088A67CC74020B\ BEA63B139B22514A08798E3404DDEF9519B3CD3A431B302B0A6DF25F14374FE1356D\ 6D51C245E485B576625E7EC6F44C42E9A637ED6B0BFF5CB6F406B7EDEE386BFB5A89\ 9FA5AE9F24117C4B1FE649286651ECE45B3DC2007CB8A163BF0598DA48361C55D39A\ 69163FA8FD24CF5F83655D23DCA3AD961C62F356208552BB9ED529077096966D670C\ 354E4ABC9804F1746C08CA18217C32905E462E36CE3BE39E772C180E86039B2783A2\ EC07A28FB5C55DF06F4C52C9DE2BCBF6955817183995497CEA956AE515D2261898FA\ 051015728E5A8AACAA68FFFFFFFFFFFFFFFF 2^3072 - 2^3008 - 1 + 2^64 * (floor(2^2942 * pi) + 1690314) /* group 15 */ FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E088A67CC74020B\ BEA63B139B22514A08798E3404DDEF9519B3CD3A431B302B0A6DF25F14374FE1356D\ 6D51C245E485B576625E7EC6F44C42E9A637ED6B0BFF5CB6F406B7EDEE386BFB5A89\ 9FA5AE9F24117C4B1FE649286651ECE45B3DC2007CB8A163BF0598DA48361C55D39A\ 69163FA8FD24CF5F83655D23DCA3AD961C62F356208552BB9ED529077096966D670C\ 354E4ABC9804F1746C08CA18217C32905E462E36CE3BE39E772C180E86039B2783A2\ EC07A28FB5C55DF06F4C52C9DE2BCBF6955817183995497CEA956AE515D2261898FA\ 051015728E5A8AAAC42DAD33170D04507A33A85521ABDF1CBA64ECFB850458DBEF0A\ 8AEA71575D060C7DB3970F85A6E1E4C7ABF5AE8CDB0933D71E8C94E04A25619DCEE3\ D2261AD2EE6BF12FFA06D98A0864D87602733EC86A64521F2B18177B200CBBE11757\ 7A615D6C770988C0BAD946E208E24FA074E5AB3143DB5BFCE0FD108E4B82D120A93A\ D2CAFFFFFFFFFFFFFFFF They both compare exactly to rfc3526. To calculate the group 16 value, I need to add more digits to pi scale=4000 /* need more digits for group 16 */ pi=4*a(1) 2^4096 - 2^4032 - 1 + 2^64 * (floor(pi * 2^3966) + 240904) /* group 16 */ FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E088A67CC74020B\ BEA63B139B22514A08798E3404DDEF9519B3CD3A431B302B0A6DF25F14374FE1356D\ 6D51C245E485B576625E7EC6F44C42E9A637ED6B0BFF5CB6F406B7EDEE386BFB5A89\ 9FA5AE9F24117C4B1FE649286651ECE45B3DC2007CB8A163BF0598DA48361C55D39A\ 69163FA8FD24CF5F83655D23DCA3AD961C62F356208552BB9ED529077096966D670C\ 354E4ABC9804F1746C08CA18217C32905E462E36CE3BE39E772C180E86039B2783A2\ EC07A28FB5C55DF06F4C52C9DE2BCBF6955817183995497CEA956AE515D2261898FA\ 051015728E5A8AAAC42DAD33170D04507A33A85521ABDF1CBA64ECFB850458DBEF0A\ 8AEA71575D060C7DB3970F85A6E1E4C7ABF5AE8CDB0933D71E8C94E04A25619DCEE3\ D2261AD2EE6BF12FFA06D98A0864D87602733EC86A64521F2B18177B200CBBE11757\ 7A615D6C770988C0BAD946E208E24FA074E5AB3143DB5BFCE0FD108E4B82D120A921\ 08011A723C12A787E6D788719A10BDBA5B2699C327186AF4E23C1A946834B6150BDA\ 2583E9CA2AD44CE8DBBBC2DB04DE8EF92E8EFC141FBECAA6287C59474E6BC05D99B2\ 964FA090C3A2233BA186515BE7ED1F612970CEE2D7AFB81BDD762170481CD0069127\ D5B05AA993B4EA988D8FDDC186FFB7DC90A6C08F4DF435C934063199FFFFFFFFFFFF\ FFFF The above was calculated using GNU bc version 1.06. -- Mark From nobody Sun Mar 9 10:14:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C65B1A02AD for ; Sun, 9 Mar 2014 10:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dx4holyqv0k for ; Sun, 9 Mar 2014 10:13:59 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by ietfa.amsl.com (Postfix) with ESMTP id D7BAD1A02A7 for ; Sun, 9 Mar 2014 10:13:58 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id n12so7558445wgh.12 for ; Sun, 09 Mar 2014 10:13:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=OIc6wXkPgqxl8XHPx1V19a2MAgmDTbAYkzHyn1gfnFo=; b=nFU2XQdv2T7jEfl9AEcHIQ+xn8LoiKVE/ttm6KL6DzJnz0aX19deW3iNdQoANBU1iW DSlBE4wW3OryuCjHGGntEYkqpehX3J6odVt48McLnn7vV+Ex2jt/oqa76eppTtN6gngR Zz1J9e+uNBqPGvS7FJEgoAkNneOfd5PzfnLCmEX1ReholpGcVyeST8fC8j7nLO3I+tWv c4lUR7t+TCUnbooZzjT9R/I45trNRiUZNuGai2VbSKI+vftqr/b8YbGYsnHPLW/76WPI DWo12NM8Knv5g1aQPLUnaEr8HK0yVkB6NpG+nwq/JhqM6en7f+QphjyTv76nR1UnXyW7 7eTQ== X-Gm-Message-State: ALoCoQmdBgqcprDL8R5XVpY4GMoFvnlvE3krlbFRoahLHSnkDURtPbDm3baeJVH2K7X1HEtj4ikq X-Received: by 10.180.185.197 with SMTP id fe5mr6007138wic.56.1394385233173; Sun, 09 Mar 2014 10:13:53 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-65-22.w86-218.abo.wanadoo.fr. [86.218.56.22]) by mx.google.com with ESMTPSA id fo6sm4291848wib.7.2014.03.09.10.13.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Mar 2014 10:13:51 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=us-ascii From: "henry.story@bblfish.net" In-Reply-To: Date: Sun, 9 Mar 2014 18:13:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7561FE8E-B27D-4EB6-9E57-0D9A4F4236CC@bblfish.net> References: <004a01cf3aea$2505d050$6f1170f0$@augustcellars.com> To: Martin Thomson X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Q1ruOxurw_ya4NKMGUgGWb1tqEM Cc: Jim Schaad , "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2014 17:14:01 -0000 On 8 Mar 2014, at 17:25, Martin Thomson = wrote: > On 8 March 2014 16:19, Jim Schaad wrote: >> There is a major requirement for renegotiation for protection of the = client >> credentials that is being used in various EAP methods as well. HTTP = is not >> the only use of this. >=20 > I'd be interested in learning whether a similar mechanism would = suffice for you. >=20 > Nonetheless, this is a decision that is being made for HTTP. > Presumably EAP could continue to use renegotiation. >=20 > I recommend you explain your use case for renegotiation, since it's at > risk in TLS 1.3. Btw, I have a use case for renegotiation that I would like to check = here. The WebID over TLS spec needs it as things stand at present: http://www.w3.org/2005/Incubator/webid/spec/tls/#authentication-sequence It's all a question of politeness: of when one should ask a client for = its identity. We need to be able to allow a well behaved site to respect people's = desire for anonymity as long as possible. On many sites most pages may not need client authentication at = all, and only a few=20 pages (which may only be accessible after a longer browse through the = site) may require it. Not having client authentication renegotiation would require the client to = authenticate to the=20 site before even having seen the first page. This would be akin to not = allowing someone=20 into a shop before they showed their ID. It may be fine in a = war/military situation, but not in a=20 commercial environment. In all shops I know of one allows people to = browse what is available without bothering them for their identity. Allowing a client to browser = information is what is going to allow the client to make a decision as to the value of = revealing her identity. Also some pages MUST NOT have client authentication. For the WebID = protocol this would be the WebID profile page. Having client authentication on that page = could result in an infinite loop, since servers can be clients too in that spec. Consider = what would happen in step 6 of the spec without renegotiation: If Alice's server was required to authenticate to get Bob's profile, = and used the WebID enabled certificate of Alice, then Bob's server would need to = authenticate Alice. This would require it to get Alice's profile. But if that also required = authentication we'd be back at=20 step 6 of the diagram mentioned above, and there would be deadlock. =20 ---- But perhaps with "Client Authentication Request Extension for (D)TLS" = [1] mentioned earlier in this thread the HTTP2.0 spec could be updated to allow the server in a 401 to = express it's capacity to accept TLS authentication too - perhaps even WebID certificate = authentication.=20 In which case browsers would be able to offer that option to their end = users. ----- Perhaps this would also solve the current problem with the need for = servers to be set up in WANT or NEED=20 mode (which is also a problem of politeness) and which I think is tied = to=20 section 7.4.6 of RFC5246 [2]. If a server is in WANT mode and asks the = client for a certificate, but the client does not wish to authenticate, then the server can = continue - by for example politely returning an HTTP 401 and a human readable error message, or by = redirecting to another page=20 ( a login page with username-password for example ). In NEED mode the = server breaks down the connection in an ugly way - since the error handling of TLS is much less advanced = than that of HTTP. I have not yet worked out why some clients - such as curl or Opera ) = only send a certificate when=20 the server is in NEED mode, and not in WANT mode. ( please let me know = ). But again with "Client Authentication Request Extension for DTLS" that = could be left to the HTTP layer to ask the client for authentication, and so perhaps that problem = would go away too... Henry [1] http://datatracker.ietf.org/doc/draft-thomson-tls-care/ [2] http://tools.ietf.org/html/rfc5246#page-55 7.4.6. Client Certificate When this message will be sent: This is the first message the client can send after receiving a ServerHelloDone message. This message is only sent if the server requests a certificate. If no suitable certificate is available, the client MUST send a certificate message containing no certificates. That is, the certificate_list structure has a length of zero. If the client does not send any certificates, the server MAY at its discretion either continue the handshake without client authentication, or respond with a fatal handshake_failure alert. Also, if some aspect of the certificate chain was unacceptable (e.g., it was not signed by a known, trusted CA), the server MAY at its discretion either continue the handshake (considering the client unauthenticated) or send a fatal alert. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Social Web Architect http://bblfish.net/ From nobody Sun Mar 9 10:34:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5B21A02AD for ; Sun, 9 Mar 2014 10:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuPIHDSFrFLH for ; Sun, 9 Mar 2014 10:34:28 -0700 (PDT) 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 33BED1A028B for ; Sun, 9 Mar 2014 10:34:28 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so7512912wgg.13 for ; Sun, 09 Mar 2014 10:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CsE7oYknwgf73RRq/ziqtVB4ycLQNbxIyjzVwq2i+Js=; b=tR/c9iKhoQAe/W/QFWrrjc2qZcDO8FMTpjJ2QT6/Ga7RLQxlZ5BM6nCbfSc9vR6mkr sN8GfL8Yq80LhEFvYdXjEo3ai+AmEQq2oCepteF2cKbyv3fyGQFuHxEncI8H/Kue+h02 4XtkQE++9pJFBgJ4qWlwNGGjpm+hOHL6fQl8mCLbY9J4JhEGtS/ajUVOMbi81VmA/xr8 R8vbXSD83E3nOERNDZL8nOqmdrtGhdPo8awS3qunaCfA3j8R7t6umOzfh6SlEXFA0QZO 4CCK4y468t5lG9eOWHoXLafqpchfgG7uOlSMYt+XtkZgmSL/k56WUbTfR5uAk+5IBhRW DgJg== MIME-Version: 1.0 X-Received: by 10.180.89.211 with SMTP id bq19mr6035858wib.58.1394386462808; Sun, 09 Mar 2014 10:34:22 -0700 (PDT) Received: by 10.227.10.196 with HTTP; Sun, 9 Mar 2014 10:34:22 -0700 (PDT) In-Reply-To: <7561FE8E-B27D-4EB6-9E57-0D9A4F4236CC@bblfish.net> References: <004a01cf3aea$2505d050$6f1170f0$@augustcellars.com> <7561FE8E-B27D-4EB6-9E57-0D9A4F4236CC@bblfish.net> Date: Sun, 9 Mar 2014 18:34:22 +0100 Message-ID: From: Martin Thomson To: "henry.story@bblfish.net" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0AaTUHcDKzhuS_LabmEp2Qwlt8k Cc: Jim Schaad , "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2014 17:34:30 -0000 On 9 March 2014 18:13, henry.story@bblfish.net wrote: > http://www.w3.org/2005/Incubator/webid/spec/tls/#authentication-sequence This looks like exactly the use case that this is intended to address. From nobody Sun Mar 9 13:55:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFBB1A02D9 for ; Sun, 9 Mar 2014 13:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3deHX7EuKG9 for ; Sun, 9 Mar 2014 13:55:34 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 981291A0384 for ; Sun, 9 Mar 2014 13:55:34 -0700 (PDT) Received: from [192.168.42.103] (h-67-100-110-239.nycm.ny.dynamic.megapath.net [67.100.110.239]) by che.mayfirst.org (Postfix) with ESMTPSA id 2A601F984 for ; Sun, 9 Mar 2014 16:55:27 -0400 (EDT) Message-ID: <531CD53D.1000603@fifthhorseman.net> Date: Sun, 09 Mar 2014 16:55:25 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: IETF TLS WG References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="M485DoE1oTGxJk3GdgC69jPTwPUfcJKsC" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jm65jLzLMa_UTxbqBwKNKdS0JDw Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2014 20:55:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --M485DoE1oTGxJk3GdgC69jPTwPUfcJKsC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/08/2014 07:05 AM, Martin Thomson wrote: > http://datatracker.ietf.org/doc/draft-thomson-tls-care/ this document seems sensible to me. minor typo in the top of page 3: the client needs to provide some indication that it might need to be authentication this should probably be: the client needs to provide some indication that it might need to be authenticated Regards, --dkg --M485DoE1oTGxJk3GdgC69jPTwPUfcJKsC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTHNVAXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc5vYP/jwyKOElY8ZAYb7wk/r56B9j WxNqw8X4W0LDClfxs3zlxE57eQL1nfA5OKs8uXC2lFrGPE2uBpqFrz8PUad2ZT+Y 4Fmz8rzIjwLSgYJ/9NvhRz6xluREB64DNqht/2Z9t3kJy6qKzvuha2P/r0FrnmC4 MUkoIjzm23q3rEtAx295ElmUpmUROBRpckNjRUgv0TnGdEhavOwKXR0Hk9HUmUBS ReCJt02lWq4YMCBLh3NVtQ9ygwGTwIj9sHJ1UAMJ1sJS8amzWrU/68mCjM22vGDv IPG30k1iFJ0nV+4CV6tLy75c95EXX6yePymI0yYiKqwvrjtpp7590E4bdxCnDnNm 8XXTb5s9s6G/jp/pRUANTaJxEu7NUdQr55TtW4irEiT0NifVPsGF2IgaFoKsRhHw XLRzw+mNtEc4ycWN0YPORiJ4cK/i3nlS5WVEE5PNIzz8ocjwgEoWAHMSJkmIS0+Y Fg2PozRUA10bnReDBs64KWJj4GKcezt+WleTnoPIjkSE2YzqMT2DxbFWbeil2hkP Y95clcoPAtqb1q9I0ACAdpqRUY8zBxJlfpEWzET4LXfTSJEK9NtPnsQlHeOxn+59 Vk0TmdYMmIZznd40LnTfz6/1KG2VLCTT04F7cqBVyLTZCIk5iubGSUld3KvgoFDL UUcmJP8Pvk2FaBMYeYGU =u4Ug -----END PGP SIGNATURE----- --M485DoE1oTGxJk3GdgC69jPTwPUfcJKsC-- From nobody Sun Mar 9 15:22:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873301A01F3 for ; Sun, 9 Mar 2014 15:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOmu2XAw45Oo for ; Sun, 9 Mar 2014 15:22:32 -0700 (PDT) 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 7E07F1A0196 for ; Sun, 9 Mar 2014 15:22:32 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id e49so2738378eek.25 for ; Sun, 09 Mar 2014 15:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yyegWQApgphchrx6WTcNMJ7/+SRH2P0deZthn8p+XzU=; b=Q7QC/uM0cu9DORLMUvvj5YN2oCl2UG8hBGS9dUMiak+mlM+7vN5eSEVV5zkXi4jqTR 9ufbMzBIptpEy+VqXx0X78Wy4F8P/7dBs+QB2dLMS0LVfbKK9uT6bvza5e7B103HM1xe JP05Fd++mlNq0pjLV7JtPZFPsMgSgZzRlJ54dxTVw+Dc4tNK6lbznme6qXY7uBlMGhi0 m7poK44rAPIwofKeCaVApK63e8XY+3xANyx48Ffgt7YZAa3Jdkn+sL4PHrg5h/6g15f9 9TegxT+u5EexKBVlp2clbHaVtc/DZf3pYwtxpXSsWemm5ArLgPY183K8PlrhJtUhbtu9 Qojg== X-Received: by 10.14.103.134 with SMTP id f6mr31994757eeg.41.1394403746908; Sun, 09 Mar 2014 15:22:26 -0700 (PDT) Received: from [192.168.1.102] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id m8sm37397439eef.14.2014.03.09.15.22.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Mar 2014 15:22:26 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: Date: Mon, 10 Mar 2014 00:22:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <506B0C5A-1EC6-427D-9FCB-8F19F85DA8C6@gmail.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Et98sLVVt-tSjQ1eS_REKSduEF8 Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2014 22:22:34 -0000 On Mar 8, 2014, at 2:05 PM, Martin Thomson = wrote: > It seems like the main use case for renegotiation is client > authentication. For two reasons: >=20 > 1. a need for client authentication is often discovered in the middle > of a session >=20 > 2. renegotiation provides confidentiality protection for the client = certificate >=20 > I think that main user of this feature is HTTP. If we are to get rid > of renegotiation (and we intend to for HTTP/2 if at all possible), > then we need some way to address these concerns. >=20 > It turns out that the main reason renegotiation causes issues is that > it can happen mid-stream, when you have the possibility for confusion > about the security properties of application data, particularly when > protocol atoms span the pair of ChangeCipherSpec messages associated > with the renegotiation. >=20 > A current proposal in HTTP/2 is to forbid renegotiation, except at the > very beginning of a connection, and only for client authentication. > (In TLS 1.3, we protect the client certificate, so the renegotiation > isn't needed at all.) That addresses point 2. >=20 > We plan to have something in HTTP that causes a client to make a new, > client-authenticated connection, so that we can address point 1. >=20 > This results in a small problem. In TLS, a server decides to request > client authentication. On a new connection, there is no context > available at the server to decide to request that the client offer a > cert. >=20 > I've submitted a draft that describes a solution for this small part > of the problem. Here: >=20 > http://datatracker.ietf.org/doc/draft-thomson-tls-care/ Hi, Martin I was the one who described this use case at the TLS meeting. I agree = that this would solve the use case.=20 Thinking about it a bit further, a TLS server (could be a web server, = but this mechanism in generic for TLS) would have three possible = configurations: 1. Always request a client certificate 2. Never request a client certificate 3. Only request a client certificate if the client offers the new = extension. For the banking and SSL-VPN websites that I talked about, #3 would be = appropriate.=20 You also need a document describing how HTML or HTTP is used to trigger = such a connection Login = with certificates Or maybe a new response code that says =93retry with client auth=94.=20 Either way, we should think what would make better sense to application = developers. Yoav= From nobody Sun Mar 9 15:54:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6EF1A022D for ; Sun, 9 Mar 2014 15:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFzEP9JQnjyr for ; Sun, 9 Mar 2014 15:54:28 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7195B1A0196 for ; Sun, 9 Mar 2014 15:54:28 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id i57so3397472yha.12 for ; Sun, 09 Mar 2014 15:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=r+l5jY7N1iUFZ9nNt60MD1rgJMtT4MSDDaKpBC9T+w0=; b=g90gH4hEQKTI3rbg3E2s7MTIG61W1hJIEe8rtEIYOI/9tAXdEeUlZevmGVlDK7WTPp j+cPGOOpJ+lrYNDJhtjsi9GVggtQHXhy5/biZDpcyxX2mKojzUQFrOFOL+7JMdRbYK63 Oo71ZJ3uGGrwdG23R1tLRY+sQULTg9wo/73sgFXNqztROFv8nFvLkjJsXD1OUsYWXaDx z1ePHLYlL9xIiwyWBKkGfS8IAbsjBe1/BAbZPbbBeC8mXP5WYe/hZcN1E/qJDpkKPX7Q miOPpv+mbwPCKK3UNKowutt6Jn+CKDVD1owalxpPoG1HMEmRaYCZTrjAUS8rPfjZFItR P/fQ== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr10321859yhi.4.1394405662127; Sun, 09 Mar 2014 15:54:22 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Sun, 9 Mar 2014 15:54:22 -0700 (PDT) In-Reply-To: <506B0C5A-1EC6-427D-9FCB-8F19F85DA8C6@gmail.com> References: <506B0C5A-1EC6-427D-9FCB-8F19F85DA8C6@gmail.com> Date: Sun, 9 Mar 2014 15:54:22 -0700 Message-ID: From: Watson Ladd To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/flfMZqDhxZMO2NYJ_bnj527z_lE Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2014 22:54:31 -0000 On Sun, Mar 9, 2014 at 3:22 PM, Yoav Nir wrote: > > On Mar 8, 2014, at 2:05 PM, Martin Thomson wro= te: > >> It seems like the main use case for renegotiation is client >> authentication. For two reasons: >> >> 1. a need for client authentication is often discovered in the middle >> of a session >> >> 2. renegotiation provides confidentiality protection for the client cert= ificate >> >> I think that main user of this feature is HTTP. If we are to get rid >> of renegotiation (and we intend to for HTTP/2 if at all possible), >> then we need some way to address these concerns. >> >> It turns out that the main reason renegotiation causes issues is that >> it can happen mid-stream, when you have the possibility for confusion >> about the security properties of application data, particularly when >> protocol atoms span the pair of ChangeCipherSpec messages associated >> with the renegotiation. >> >> A current proposal in HTTP/2 is to forbid renegotiation, except at the >> very beginning of a connection, and only for client authentication. >> (In TLS 1.3, we protect the client certificate, so the renegotiation >> isn't needed at all.) That addresses point 2. >> >> We plan to have something in HTTP that causes a client to make a new, >> client-authenticated connection, so that we can address point 1. >> >> This results in a small problem. In TLS, a server decides to request >> client authentication. On a new connection, there is no context >> available at the server to decide to request that the client offer a >> cert. >> >> I've submitted a draft that describes a solution for this small part >> of the problem. Here: >> >> http://datatracker.ietf.org/doc/draft-thomson-tls-care/ > > Hi, Martin > > I was the one who described this use case at the TLS meeting. I agree tha= t this would solve the use case. > > Thinking about it a bit further, a TLS server (could be a web server, but= this mechanism in generic for TLS) would have three possible configuration= s: > 1. Always request a client certificate > 2. Never request a client certificate > 3. Only request a client certificate if the client offers the new extens= ion. I don't get this last one. Why doesn't the client just show the certificate and proof that it did the negotiation instead of telling the server to ask for it? I'm sure there is a good reason for it which I don't see, but as it stands it's like the recurrent laryngeal nerve of the giraffe: the result of lots of small, sensible changes, leading to a facially ridiculous result. (For those not aware of the details of giraffe anatomy, this is a nerve that goes from the skull down to the aorta in the chest of the giraffe, wraps around it, and comes back up the neck to innervate the larynx, just a few inches away from the start). Sincerely, Watson Ladd > > For the banking and SSL-VPN websites that I talked about, #3 would be app= ropriate. > > You also need a document describing how HTML or HTTP is used to trigger s= uch a connection > Login with certificates > > Or maybe a new response code that says =E2=80=9Cretry with client auth=E2= =80=9D. > > Either way, we should think what would make better sense to application d= evelopers. > > Yoav > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Mar 9 16:26:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426AA1A023D for ; Sun, 9 Mar 2014 16:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 q7T8iEwpJee0 for ; Sun, 9 Mar 2014 16:25:56 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by ietfa.amsl.com (Postfix) with ESMTP id E6E221A0286 for ; Sun, 9 Mar 2014 16:25:54 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 1690A69964; Mon, 10 Mar 2014 01:25:47 +0200 (EET) Date: Mon, 10 Mar 2014 01:25:47 +0200 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20140309232547.GA11565@LK-Perkele-VII> References: <506B0C5A-1EC6-427D-9FCB-8F19F85DA8C6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ll1BYjF7NM6Aq0KxPLK6iXZjsFM Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2014 23:25:58 -0000 On Sun, Mar 09, 2014 at 03:54:22PM -0700, Watson Ladd wrote: > > I don't get this last one. Why doesn't the client just show the > certificate and proof that it did the negotiation instead of telling > the server to ask for it? TLS Spec says that client MUST use one of the algos mentioned in CertificateRequest (but there is no direct MUST NOT or SHOULD NOT about sending Certificate/CertificateVerify without CertificateRequest). -Ilari From nobody Mon Mar 10 01:14:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0D91A03F0 for ; Mon, 10 Mar 2014 01:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hil4fP4u1FxI for ; Mon, 10 Mar 2014 01:14:25 -0700 (PDT) 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 3A4531A0320 for ; Mon, 10 Mar 2014 01:14:25 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so7628682wgh.4 for ; Mon, 10 Mar 2014 01:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Jw8X5VLCYZg9cNm2Zi8Dt5JlAS7ai4bc53I0BIlJhoo=; b=rhnz8Zb1ilZCXkQ4Ih2JGrHnPVcFWhBQd3egCFbrTJd9ZqlFIbtZPbFtm1OQOPMzbY rDmfrrq0/X5TrNoci0KsI1GKPrXg1wQoLgXUYG8+X8BJ9YHViDHbi8oDXc+s37wamex2 O14fmih5urMqHERPdOAbaXSvDf0KrRXpTzWBIpSkRJvsVzkDOptljpafW4sK9sCWtYAr 0D+/+v/m3gh2NJvgKjGjje6b65QEE8m/jYKljNoLJR5PWz3tSvBwBl2mzrZCtd/9NlAj Bzo3rAHbwXVTLfxxxDSfvQu5ypDMWGMEoB2iOdwc45P0c1j+n2CI03b3jCqGwbsYLNu/ bFpg== MIME-Version: 1.0 X-Received: by 10.180.75.202 with SMTP id e10mr7783521wiw.50.1394439259619; Mon, 10 Mar 2014 01:14:19 -0700 (PDT) Received: by 10.227.10.196 with HTTP; Mon, 10 Mar 2014 01:14:19 -0700 (PDT) In-Reply-To: <506B0C5A-1EC6-427D-9FCB-8F19F85DA8C6@gmail.com> References: <506B0C5A-1EC6-427D-9FCB-8F19F85DA8C6@gmail.com> Date: Mon, 10 Mar 2014 09:14:19 +0100 Message-ID: From: Martin Thomson To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vnsKFL_x2coNCnoGCHYAMiT5HVA Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 08:14:27 -0000 On 9 March 2014 23:22, Yoav Nir wrote: > 1. Always request a client certificate FYI, most software has a secondary configuration on this point: whether to reject the connection if a certificate is not provided. This makes the request from the server optional to comply with (or not). > You also need a document describing how HTML or HTTP is used to trigger such a connection http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/ From nobody Mon Mar 10 01:17:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028581A03FF for ; Mon, 10 Mar 2014 01:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqQuPAcOlynm for ; Mon, 10 Mar 2014 01:17:14 -0700 (PDT) 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 CC8001A03F6 for ; Mon, 10 Mar 2014 01:17:12 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so8065765wgg.1 for ; Mon, 10 Mar 2014 01:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hzHFxwGvw7fdk6paxFpOVrPxuKlGcOWiEIF74GFFHIc=; b=zKe0496uVOWNrmPuOP9LVea9qQsuWFaVIwVSGj4gGt8BzEdOy5VEJGTM9QrCY3ka1Y sT9j4zHSjGDtgRsqlU92p0TcyA13MC/8nbuuBwDdWLEGZm0gIMORx5lM1Aupn9Yqf1oA p8PrxVnETG5DMK3AixakBx+KjWQINPWo/yE7Bposovb+xOTA1D1vcm30Sn3SwneJzLbc 1WY7/zP9CrMNJQWzfPpt/YSDo5bIioUFRnPKSSKeUtZJ/ZsXI5TyV2DB+ECIRGeCCXZF uwtkjDMHSj1XzCwVnx28CmOBXfREfMVb/adnpDujBJQSfVsNAacKQ8a3NQUdcLKNZm3S 1gJg== MIME-Version: 1.0 X-Received: by 10.180.106.225 with SMTP id gx1mr6835976wib.50.1394439427237; Mon, 10 Mar 2014 01:17:07 -0700 (PDT) Received: by 10.227.10.196 with HTTP; Mon, 10 Mar 2014 01:17:07 -0700 (PDT) In-Reply-To: <20140309232547.GA11565@LK-Perkele-VII> References: <506B0C5A-1EC6-427D-9FCB-8F19F85DA8C6@gmail.com> <20140309232547.GA11565@LK-Perkele-VII> Date: Mon, 10 Mar 2014 09:17:07 +0100 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bB30i1cEW4yiB7nPI5m2OhTABrk Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 08:17:16 -0000 On 10 March 2014 00:25, Ilari Liusvaara wrote: > On Sun, Mar 09, 2014 at 03:54:22PM -0700, Watson Ladd wrote: >> >> I don't get this last one. Why doesn't the client just show the >> certificate and proof that it did the negotiation instead of telling >> the server to ask for it? > > TLS Spec says that client MUST use one of the algos mentioned in > CertificateRequest (but there is no direct MUST NOT or SHOULD NOT > about sending Certificate/CertificateVerify without CertificateRequest). I don't know what this does to existing implementations, but I'd imagine that it would be surprising. More so if the algorithm or certificate type wasn't a supported type. From nobody Mon Mar 10 02:21:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B31A1A03FB for ; Mon, 10 Mar 2014 02:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 kvVnKMXk2vbS for ; Mon, 10 Mar 2014 02:21:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 683CC1A0407 for ; Mon, 10 Mar 2014 02:21:49 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2A9Lg0t006074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Mar 2014 05:21:43 -0400 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 s2A9LeiL001256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 10 Mar 2014 05:21:42 -0400 Message-ID: <1394443300.25354.63.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Martin Thomson Date: Mon, 10 Mar 2014 10:21:40 +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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ipftaowK5quJK6wbw0TBIK6wFxg Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 09:21:52 -0000 On Sat, 2014-03-08 at 12:05 +0000, Martin Thomson wrote: > It seems like the main use case for renegotiation is client > authentication. For two reasons: Only if you restrict it to the HTTPS protocol. Otherwise renegotiation is mainly used to rekey and reset the TLS and DTLS record sequence numbers. regards, Nikos From nobody Mon Mar 10 02:51:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB2F1A0411 for ; Mon, 10 Mar 2014 02:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFMap5Tl4khN for ; Mon, 10 Mar 2014 02:51:20 -0700 (PDT) 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 94C811A0410 for ; Mon, 10 Mar 2014 02:51:20 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so5854093wgh.15 for ; Mon, 10 Mar 2014 02:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TJ4vPWwAuUeGbrgit6Pgy52OUWqYWOxok92SHGwRVkY=; b=UHEBVdDlVxIgBJnkI9AbPHlnUDBanLafxo6dfv53DR1ezCz//aiRTlQ7i8Uc8PDPqq aHSHupmxUUk8xAT7fMxrivZn/RDcsHcMTEAvQKK/eyM/wU5R6nawsyO8COFk79WO25r1 pLvt2PKUXX9RyAjAz7A+MgCCO9057kMqYklB8Sue5Eyt4ykd75vGzB6s84LNluTTINeC +7SdsNMR6wpRe+b/YRQeO0dYyA0Bn/iheSheq+dewRrz1QUNnt33NC3Dins722zaYDXO IA7VJRhgAJ/P1HRW0+GV0tA9xdSwGFZthcYtmjmbkajmRlgmshtfMHuWbiAq5N0ML+pB CZVg== MIME-Version: 1.0 X-Received: by 10.180.77.129 with SMTP id s1mr7139288wiw.56.1394445074859; Mon, 10 Mar 2014 02:51:14 -0700 (PDT) Received: by 10.227.10.196 with HTTP; Mon, 10 Mar 2014 02:51:14 -0700 (PDT) In-Reply-To: <1394443300.25354.63.camel@dhcp-2-127.brq.redhat.com> References: <1394443300.25354.63.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 10 Mar 2014 10:51:14 +0100 Message-ID: From: Martin Thomson To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FsN4uaHWGp_FF_0fHFJQ-gB_FIc Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 09:51:22 -0000 On 10 March 2014 10:21, Nikos Mavrogiannopoulos wrote: > renegotiation > is mainly used to rekey and reset the TLS and DTLS record sequence > numbers. This is exactly the sort of thing I wanted to flush out. There are two questions we need to resolve: - whether we can avoid having to define renegotiation for TLS 1.3 - whether we can avoid having to deal with renegotiation for HTTP (HTTP/2 primarily) This effort is primarily focused on addressing the latter, which will help us unblock some critical HTTP/2 stuff. For the former, when ekr went through the reasons for having renegotiation, it was pointed out that a small change could avoid the sequence number exhaustion/key overuse issues. If we can work on progressively identifying important uses and providing non-renegotiation-based ways to address them, that would be good. From nobody Mon Mar 10 04:35:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BE01A03FA for ; Mon, 10 Mar 2014 04:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCYzYWy83DtU for ; Mon, 10 Mar 2014 04:35:19 -0700 (PDT) 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 1D8F81A03D5 for ; Mon, 10 Mar 2014 04:35:18 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id x48so8486094wes.35 for ; Mon, 10 Mar 2014 04:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xQQ5FvxZXgvvwwTTceC3H+wBG69V6lslk77scX6WjtM=; b=D8P3G9EKZ7hshzr3h0dEaRJQ3nNv3fk9CN73XRH5dGQrdvwAWsg1Nimop1Grg4rCfF 1DGUxHv5M1kjzlnVy61+NnF10BompDFB7iVW8Sz48r5i9h8wWrDWA1hJiWUrY/B/+8MR EsJrOE6SLs9gtncfGQwkpmgMokNlh86cMUvZ7KAZPkOvwurEuEHWq3aP0x5fgn2wJ/EG gLDjXg12DBV9+kyOdmFBHneSc+5YdVDwkNBMpU89Wo7UVTCOp8aRSqJJAyj4Cf/uJkz3 dzY5/fuAbMIrZ0auqGGfH4rf+Tc5o+MOt8VaeKnLiTeUCpVOTQuFMC+KE8VFKoFSLPdW 8IFA== MIME-Version: 1.0 X-Received: by 10.180.210.171 with SMTP id mv11mr7602929wic.44.1394451313407; Mon, 10 Mar 2014 04:35:13 -0700 (PDT) Received: by 10.194.89.1 with HTTP; Mon, 10 Mar 2014 04:35:13 -0700 (PDT) In-Reply-To: References: <506B0C5A-1EC6-427D-9FCB-8F19F85DA8C6@gmail.com> Date: Mon, 10 Mar 2014 13:35:13 +0200 Message-ID: From: Yoav Nir To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c25d363138b404f43effa3 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4jq02_NEOy5W_2-foK73rgGVLyU Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 11:35:21 -0000 --001a11c25d363138b404f43effa3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 10, 2014 at 10:14 AM, Martin Thomson wrote: > On 9 March 2014 23:22, Yoav Nir wrote: > > 1. Always request a client certificate > > FYI, most software has a secondary configuration on this point: > whether to reject the connection if a certificate is not provided. > This makes the request from the server optional to comply with (or > not). > Yes, but the user experience is the same whether the server has marked the client authentication as optional or mandatory - the browser pops us a certificate selector, and you don't want that on the landing page. > You also need a document describing how HTML or HTTP is used to trigger > such a connection > > http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/ > I would have preferred a response code (like "4xx client authentication needed"), but this works as well. How does the server tell new clients (that support this extension) apart from older clients, for which you still have to use renegotiation (in TLS 1.2 or course...)? Sending this to old clients would result in breakage. Yoav --001a11c25d363138b404f43effa3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 10, 2014 at 10:14 AM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
On 9 March 2014 23:22, Yoav = Nir <ynir.ietf@gmail.com> = wrote:
> =A01. Always request a client certificate

FYI, most software has a secondary configuration on this point:
whether to reject the connection if a certificate is not provided.
This makes the request from the server optional to comply with (or
not).

Yes, but the user experience is t= he same whether the server has marked the client authentication as optional= or mandatory - the browser pops us a certificate selector, and you don'= ;t want that on the landing page.

> You also need a document describing how HTML or HTTP is used to trigge= r such a connection

http://datatracker.ietf.org/doc/draft-thomson-httpbis= -catch/

I would have prefer= red a response code (like "4xx client authentication needed"), bu= t this works as well.

How does the = server tell new clients (that support this extension) apart from older clie= nts, for which you still have to use renegotiation (in TLS 1.2 or course...= )? Sending this to old clients would result in breakage.

Yoav
--001a11c25d363138b404f43effa3-- From nobody Mon Mar 10 04:43:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508FD1A0420 for ; Mon, 10 Mar 2014 04:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfgxNUMKdAMv for ; Mon, 10 Mar 2014 04:43:38 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id F2A7F1A041F for ; Mon, 10 Mar 2014 04:43:37 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id n12so8519008wgh.0 for ; Mon, 10 Mar 2014 04:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ai8hf5BOJN9eCOi4YI1b8Pi7nfvf+GweUcN9CdkGmwY=; b=evrd69nOgwGAHHZANP8qVCh8FSDcAr5OEnf5eYSly8z8qKwKJS+gpyjEyjAZ8Ovfaf GmULwqzxwqw+0J4PP5JqhNw5IZIffLIvpWzUvlxrUXU2L0409ZYnhvIeRwBWpAbJcuPB TciUcTgWsfxYGyewcHxVCWW2s3E1OAyIDXxLjsOAqfyBrQaSSwDBq1vryD4jH1j7nagy wOmUF2eF0vuAfQ4WqyBx5723y0UtsEYj3Ru9FiHaxkVaXi/ik8R9nPDaqOBmFIJxFbI9 u87zFOkKxEqoSfI3Ztd0e6c3lNlvUK8fJgDUFfsAfyD1nAaXuNxfafefp9/+FJTjUaM0 Hm9A== MIME-Version: 1.0 X-Received: by 10.180.12.14 with SMTP id u14mr8664780wib.0.1394451812245; Mon, 10 Mar 2014 04:43:32 -0700 (PDT) Received: by 10.194.89.1 with HTTP; Mon, 10 Mar 2014 04:43:32 -0700 (PDT) In-Reply-To: References: <506B0C5A-1EC6-427D-9FCB-8F19F85DA8C6@gmail.com> Date: Mon, 10 Mar 2014 13:43:32 +0200 Message-ID: From: Yoav Nir To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11c23ed2ece84704f43f1cf9 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YB8w06k15dJif7WJ9dAFpNZ1Wa4 Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 11:43:40 -0000 --001a11c23ed2ece84704f43f1cf9 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 10, 2014 at 12:54 AM, Watson Ladd wrote: > > I don't get this last one. Why doesn't the client just show the > certificate and proof that it did the negotiation instead of telling > the server to ask for it? In TLS the server has to request a certificate before the client can provide one. There is, however, a UI issue with the server requesting a certificate: the browser pops up a "certificate picker" asking you to choose which certificate to show. So if I go to https://www.bigbank.com or https://sslvpn.example.com I don't want to get the picker immediately. Maybe I just want to read generic information about the bank. So there will typically be a button or a hyperlink, and when I click that, the certificate picker pops up. But the only way the server knows that I clicked this is that it gets a request (like "GET /login_with_certs HTTP/1.1"). Today when it gets this request, it triggers the TLS layer to send a HelloRequest, and cause a renegotiation with a certificate request. Martin's proposal is to signal to the client in the HTTP layer to initiate a whole new connection, and in this new connection the client signals to the server that it is OK to request a certificate. HTH Yoav --001a11c23ed2ece84704f43f1cf9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 10, 2014 at 12:54 AM, Watson Ladd <= ;watsonbladd@gma= il.com> wrote:

I don't get this last one. Why doesn't the client just = show the
certificate and proof that it did the negotiation instead of telling
the server to ask for it?

In TLS the serve= r has to request a certificate before the client can provide one. There is,= however, a UI issue with the server requesting a certificate: the browser = pops up a "certificate picker" asking you to choose which certifi= cate to show. So if I go to https://www= .bigbank.com=A0 or https://sslvp= n.example.com=A0 I don't want to get the picker immediately. Maybe = I just want to read generic information about the bank.

So there will typically be a button or a hyperlink, and when I click th= at, the certificate picker pops up. But the only way the server knows that = I clicked this is that it gets a request (like "GET /login_with_certs = HTTP/1.1"). Today when it gets this request, it triggers the TLS layer= to send a HelloRequest, and cause a renegotiation with a certificate reque= st. Martin's proposal is to signal to the client in the HTTP layer to i= nitiate a whole new connection, and in this new connection the client signa= ls to the server that it is OK to request a certificate.

HTH

Yoav
--001a11c23ed2ece84704f43f1cf9-- From nobody Mon Mar 10 05:32:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050451A01CC for ; Mon, 10 Mar 2014 05:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUEdgbLi9XuJ for ; Mon, 10 Mar 2014 05:32:47 -0700 (PDT) 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 D03211A042A for ; Mon, 10 Mar 2014 05:32:46 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so6211906wgh.27 for ; Mon, 10 Mar 2014 05:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=egIl+vZTrXhHAfzsmhQpp9stZ/ouYumsVzhbxtdKHB8=; b=ZFyR0pP9w3j7nT/iBIqIRv80u8nLlyoTR3Pp3NCOyhK5I2sxFg1PXzC3QMA2Qa85pv kSohOI6BZzHeUHHhiR4SQeUqWTPKLO7+ZB1bt0k9JZd+BTueSgeDOYMGeW0T4W9qI2n7 kTnTS5q+y48xiO9ghIjnfxRacr4ozonw4DHQS/Q+RL/yLqPK8K5dqWikQreeoOZ0z+ql zxRu+oL6NR9sttstGb/JrrEIUkTjq3F/Oibz6dQkI6+f1Zk571PdJI70Yr8YAgdmCls4 /uQ5FPKNqiZIqA4y0u6rB3nRtKxjUvHSoup3oyaEa2uhETuvmTRg1LkjqemsAhbJW9zZ SF9A== MIME-Version: 1.0 X-Received: by 10.180.185.197 with SMTP id fe5mr8674272wic.56.1394454761046; Mon, 10 Mar 2014 05:32:41 -0700 (PDT) Received: by 10.227.10.196 with HTTP; Mon, 10 Mar 2014 05:32:40 -0700 (PDT) In-Reply-To: References: <506B0C5A-1EC6-427D-9FCB-8F19F85DA8C6@gmail.com> Date: Mon, 10 Mar 2014 13:32:40 +0100 Message-ID: From: Martin Thomson To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qKYX-fueBYV70uLHsALjEkN56Rc Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 12:32:49 -0000 On 10 March 2014 12:35, Yoav Nir wrote: > How does the server tell new clients (that support this extension) apart > from older clients, for which you still have to use renegotiation (in TLS > 1.2 or course...)? Sending this to old clients would result in breakage. Good question. Probably best pursued in httpbis though. From nobody Mon Mar 10 06:03:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172CD1A042E for ; Mon, 10 Mar 2014 06:03:48 -0700 (PDT) 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 I3FRFa1rP1ld for ; Mon, 10 Mar 2014 06:03:46 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3C61A0434 for ; Mon, 10 Mar 2014 06:03:46 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so13172wib.16 for ; Mon, 10 Mar 2014 06:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1JMvqi5yA/RCq4kKY95vM9Pe4Z8rbrrvSTizf1noCfw=; b=EAxChfzNf+bpZn60YkDuXvkXWtJTSEEPM230AJ2sahXtBxEOdEd+c2xuevu5sPFS4m nAYojVflbnbbYh/eDbUkJGILCxaNowwWuj1kXSOm3KlgoWrv/CYCDrAx1W3+4xwHYKt+ 2J86p7gc9PJc59K7YDpi7bveBETk54sWHLpnOFWO+R+VLz+bcDydCaWZfh6FRdb5K8JX U6+ZjumIaikitRCLgFAIU6IEwb3poBPq3M6Uvrq8RtpDP3WYHH3wfHRYGj1IVSzQNAHC Ipka0OAkMNALWNOalEQxoWEBzm7PmfxxpzdjilC+wmJHV4hBa4tEO6T/WGGrKx0lqkQ5 YmEA== X-Received: by 10.194.59.210 with SMTP id b18mr1329784wjr.60.1394456620748; Mon, 10 Mar 2014 06:03:40 -0700 (PDT) Received: from [192.168.1.99] (188.110.176.95.rev.sfr.net. [95.176.110.188]) by mx.google.com with ESMTPSA id t6sm13604290wix.4.2014.03.10.06.03.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Mar 2014 06:03:39 -0700 (PDT) Message-ID: <531DB828.9070503@gmail.com> Date: Mon, 10 Mar 2014 14:03:36 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Yoav Nir , Watson Ladd References: <506B0C5A-1EC6-427D-9FCB-8F19F85DA8C6@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zJ_EGSx2K8tD5FSI46TsVWPABDc Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 13:03:48 -0000 On 2014-03-10 12:43, Yoav Nir wrote: > > > > On Mon, Mar 10, 2014 at 12:54 AM, Watson Ladd > wrote: > > > I don't get this last one. Why doesn't the client just show the > certificate and proof that it did the negotiation instead of telling > the server to ask for it? > > > In TLS the server has to request a certificate before the client can provide one. There is, however, a UI issue with the server requesting a certificate: the browser pops up a "certificate picker" asking you to choose which certificate to show. So if I go to https://www.bigbank.com or https://sslvpn.example.com I don't want to get the picker immediately. Maybe I just want to read generic information about the bank. > > So there will typically be a button or a hyperlink, and when I click that, the certificate picker pops up. But the only way the server knows that I clicked this is that it gets a request (like "GET /login_with_certs HTTP/1.1"). Today when it gets this request, it triggers the TLS layer to send a HelloRequest, and cause a renegotiation with a certificate request. Martin's proposal is to signal to the client in the HTTP layer to initiate a whole new connection, and in this new connection the client signals to the server that it is OK to request a certificate. > If this is addressed, server-initiated logout must be addressed as well, otherwise application-level client-side PKI login will remain the best solution. Google's U2F does this so it can't be that bad. Personally I think it is too late making HTTPS CCA (Client Certificate Authentication) generally useful since this would affect every part of the infrastructure and that takes forever. Anders > HTH > > Yoav > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Mar 10 07:35:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905481A0473 for ; Mon, 10 Mar 2014 07:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcapV3lkSmh7 for ; Mon, 10 Mar 2014 07:34:58 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5821A0447 for ; Mon, 10 Mar 2014 07:34:58 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8A0062855D; Mon, 10 Mar 2014 14:34:52 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 788DE2854B; Mon, 10 Mar 2014 14:34:52 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 761638004B; Mon, 10 Mar 2014 14:34:52 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.104]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 10 Mar 2014 10:34:51 -0400 From: "Salz, Rich" To: Martin Thomson , "tls@ietf.org" Date: Mon, 10 Mar 2014 10:34:51 -0400 Thread-Topic: [TLS] Renegotiation and client authentication Thread-Index: Ac86xreCab1JOFPfRN+HJMJDkGn7YABpx4/A Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AB351@USMBX1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wT_npwcggYKHliJQ_kuy9o614GE Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 14:34:59 -0000 > It seems like the main use case for renegotiation is client authenticatio= n. For two reasons: I agree. Does it make sense to therefore define a new "who are you" messag= e that the client can send to the server? /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Mon Mar 10 07:41:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E389E1A0437 for ; Mon, 10 Mar 2014 07:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0aIm4apVF9r for ; Mon, 10 Mar 2014 07:41:25 -0700 (PDT) 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 6852D1A0434 for ; Mon, 10 Mar 2014 07:41:25 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so8726105wes.18 for ; Mon, 10 Mar 2014 07:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lamKZARYK2H89nmbeOaCak+ycyiPGGuKse8qpAeoTQY=; b=uWHByhuDQGk0vStfRkL4Z4ogN8J3krECGgFEgzSaoZhOynZT3qrZUvUBSjPNs+uV36 WJgdv0YcQy+bcvxbBXpH0tOwkAFSLMTOsp21I4SuLAIQunIuku5C7nJltPysMMMiJx8e z4YHZqQ9eFnXpbwrILvLVZ8ovGel/mopAt+nLbyyGoFXIwvDmT5ZZkRnBc/3S7Wkdzob 7VmUmnW3xojp0Y+a3gPctU944DQtx9YLLdI8dcmBw3oG+Ietub8XB/yM78xSIPzituVQ F8HxXfiByxJYQSdZhiFQPObMsmdVdHL4XpQ4Z7HFoK+AV+MmnfwqRtsrieRIJa0S+a83 1gVQ== MIME-Version: 1.0 X-Received: by 10.194.236.9 with SMTP id uq9mr31299844wjc.31.1394462479638; Mon, 10 Mar 2014 07:41:19 -0700 (PDT) Received: by 10.227.10.196 with HTTP; Mon, 10 Mar 2014 07:41:19 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AB351@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AB351@USMBX1.msg.corp.akamai.com> Date: Mon, 10 Mar 2014 15:41:19 +0100 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6LWa7xY2Egg297iD9PgDEMenqvE Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 14:41:29 -0000 On 10 March 2014 15:34, Salz, Rich wrote: > I agree. Does it make sense to therefore define a new "who are you" message that the client can send to the server? Do you mean ClientHello? Or did you mean server to client? I've tried to capture that in http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/ From nobody Mon Mar 10 07:55:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359AE1A0457 for ; Mon, 10 Mar 2014 07:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVND1Txnyy3F for ; Mon, 10 Mar 2014 07:55:13 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id B3B031A0450 for ; Mon, 10 Mar 2014 07:55:13 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 53B8C284E8; Mon, 10 Mar 2014 14:55:08 +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 417F1284DE; Mon, 10 Mar 2014 14:55:08 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 3A9992177; Mon, 10 Mar 2014 14:55:08 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.104]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Mon, 10 Mar 2014 10:55:07 -0400 From: "Salz, Rich" To: Martin Thomson Date: Mon, 10 Mar 2014 10:55:07 -0400 Thread-Topic: [TLS] Renegotiation and client authentication Thread-Index: Ac88btCm7MFYWo+hQd+THjFVHBde/gAAc9ig Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AB37C@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AB351@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TdWQ1YPrqEUormpL4uUxXLknP4Y Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 14:55:15 -0000 PiA+IEkgYWdyZWUuICBEb2VzIGl0IG1ha2Ugc2Vuc2UgdG8gdGhlcmVmb3JlIGRlZmluZSBhIG5l dyAid2hvIGFyZSB5b3UiIG1lc3NhZ2UgdGhhdCB0aGUgY2xpZW50IGNhbiBzZW5kIHRvIHRoZSBz ZXJ2ZXI/DQoNCj4gRG8geW91IG1lYW4gQ2xpZW50SGVsbG8/ICBPciBkaWQgeW91IG1lYW4gc2Vy dmVyIHRvIGNsaWVudD8NCg0KQXJnaC4gIEkgbWVhbnQgc2VydmVyIHRvIGNsaWVudC4gIFRoYW5r cy4NCg0KCS9yJA0KDQotLSAgDQpQcmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXINCkFrYW1haSBU ZWNobm9sb2d5DQpDYW1icmlkZ2UsIE1BDQo= From nobody Mon Mar 10 09:09:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FCB1A04E9; Mon, 10 Mar 2014 09:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0grVA8qYCcwb; Mon, 10 Mar 2014 09:09:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE62C1A0538; Mon, 10 Mar 2014 09:08:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140310160851.23937.69338.idtracker@ietfa.amsl.com> Date: Mon, 10 Mar 2014 09:08:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xNxftkMjLHyALoKaXAXdR-q83y0 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-encrypt-then-mac-00.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: Mon, 10 Mar 2014 16:09:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Encrypt-then-MAC for TLS and DTLS Author : Peter Gutmann Filename : draft-ietf-tls-encrypt-then-mac-00.txt Pages : 7 Date : 2014-03-10 Abstract: This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of TLS'/DTLS' existing MAC-then-encrypt one, which has been the subject of a number of security vulnerabilities over a period of many years. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-encrypt-then-mac-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/ From nobody Mon Mar 10 12:07:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CD71A06A4 for ; Mon, 10 Mar 2014 12:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WppjyQfaXIVD for ; Mon, 10 Mar 2014 12:06:58 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id 590011A0675 for ; Mon, 10 Mar 2014 12:06:58 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 12A6533D0BD; Mon, 10 Mar 2014 19:06:53 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Martin Thomson References: <1394443300.25354.63.camel@dhcp-2-127.brq.redhat.com> From: Geoffrey Keating Date: 10 Mar 2014 12:06:52 -0700 In-Reply-To: Message-ID: Lines: 36 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cYiTIdXd4OaeoCw4MfYFVx_JZT8 Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 19:07:01 -0000 Martin Thomson writes: > On 10 March 2014 10:21, Nikos Mavrogiannopoulos wrote: > > renegotiation > > is mainly used to rekey and reset the TLS and DTLS record sequence > > numbers. > > This is exactly the sort of thing I wanted to flush out. There are > two questions we need to resolve: > > - whether we can avoid having to define renegotiation for TLS 1.3 > > - whether we can avoid having to deal with renegotiation for HTTP > (HTTP/2 primarily) > > This effort is primarily focused on addressing the latter, which will > help us unblock some critical HTTP/2 stuff. For HTTP, the most common case of renegotiation seems to be requesting a client certificate. You could deal with this in TLS 1.3 by allowing the server (or, either end) to request a certificate validation at any point, without otherwise renegotiating the connection parameters. What is signed would need to be a hash of all the handshake messages to this point, or some other unique identifier of this connection. TLS 1.3 will need to provide such an identifier anyway, so using it here makes sense. I'd suggest making this the only way that signing certificates are used in the protocol, so instead of the current approach where the server signs the DH parameters and the cookies, the connection would start anonymously and the server would authenticate the connection separately. This can even happen encrypted, with no extra round-trips: send the verifier and associated certificates immediately after the ChangeCipherSpec message. From nobody Mon Mar 10 12:35:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2991A064C for ; Mon, 10 Mar 2014 12:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 AUol53F4VdVZ for ; Mon, 10 Mar 2014 12:35:11 -0700 (PDT) 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 44F451A0639 for ; Mon, 10 Mar 2014 12:35:11 -0700 (PDT) Received: from [173.75.83.129] (helo=Williams-MacBook-Pro.local) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WN5ya-0004xD-Gz; Mon, 10 Mar 2014 15:35:04 -0400 Date: Mon, 10 Mar 2014 12:35:03 -0700 From: Bill Frantz To: "Salz, Rich" X-Priority: 3 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AB37C@USMBX1.msg.corp.akamai.com> 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7955391781c21877c92bde0702088c3cab350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.129 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zP0EC2Ctx-pxsAl9Y5q8IFXTFKw Cc: tls@ietf.org Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 19:35:13 -0000 On 3/10/14 at 7:55 AM, rsalz@akamai.com (Salz, Rich) wrote: >>>I agree. Does it make sense to therefore define a new "who are you" mes= sage that the client can >send to the server? > >>Do you mean ClientHello? Or did you mean server to client? > >Argh. I meant server to client. Thanks. This idea seems to be the right direction. We already have a=20 encrypted connection. A message from server to client, "who are=20 you" either at the TLS layer or at the HTTP layer would allow=20 the client to return its certificate. If we also use the client's private key to sign the master=20 secret, or something derived from the master secret, we have a=20 second check that there is no MIM. Cheers - Bill -------------------------------------------------------------- Bill Frantz | There are now so many exceptions to the 408-356-8506 | Fourth Amendment that it operates only by www.pwpconsult.com | accident. - William Hugh Murray From nobody Mon Mar 10 13:03:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0481A04AA for ; Mon, 10 Mar 2014 13:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6of_pwY9IvIp for ; Mon, 10 Mar 2014 13:03:10 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 896631A03FC for ; Mon, 10 Mar 2014 13:03:10 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 126872852D; Mon, 10 Mar 2014 20:03:05 +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 F12F02852C; Mon, 10 Mar 2014 20:03:04 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id DC0E520AA; Mon, 10 Mar 2014 20:03:04 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.104]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Mon, 10 Mar 2014 16:03:04 -0400 From: "Salz, Rich" To: Bill Frantz Date: Mon, 10 Mar 2014 16:03:03 -0400 Thread-Topic: [TLS] Renegotiation and client authentication Thread-Index: Ac88l9gTaIyTEjsxRseoYg/lNxwvqQAA8l8g Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D4FD8@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AB37C@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/o8mQ5oxG97VmUVfoUWie1_MY40k Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 20:03:12 -0000 U2V2ZXIgc2VuZHMgYSBjaGFsbGVuZ2UsIGNsaWVudCBzaWducyBpdC4gIE5vIG5lZWQgdG8gdGll IHRoZSBwcm9vZiBvZiBwb3NzZXNzaW9uIHRvIHRoZSBjaGFubmVsLCBzaW5jZSB3ZSdyZSBleHBs aWNpdGx5IE5PVCByZW5lZ290aWF0aW5nIGFueSBvZiB0aGUgIGNoYW5uZWwgcGFyYW1zLg0KDQoJ L3IkDQoNCi0tICANClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcg0KQWthbWFpIFRlY2hub2xv Z3kNCkNhbWJyaWRnZSwgTUENCg0K From nobody Mon Mar 10 13:15:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764931A049C for ; Mon, 10 Mar 2014 13:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGNgQZtRyrh4 for ; Mon, 10 Mar 2014 13:15:02 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id BDB291A024B for ; Mon, 10 Mar 2014 13:15:02 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B3E15F984; Mon, 10 Mar 2014 16:14:55 -0400 (EDT) Message-ID: <531E1D33.20601@fifthhorseman.net> Date: Mon, 10 Mar 2014 16:14:43 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: "Salz, Rich" , Bill Frantz References: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AB37C@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D4FD8@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D4FD8@USMBX1.msg.corp.akamai.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gAJl20fXVoRt53hdoI2knqWCldRWP4TWc" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gOyvLPYZORzwyDn1kH-O-AGi_ik Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 20:15:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gAJl20fXVoRt53hdoI2knqWCldRWP4TWc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/10/2014 04:03 PM, Salz, Rich wrote: > Sever sends a challenge, client signs it. No need to tie the proof of = possession to the channel, since we're explicitly NOT renegotiating any o= f the channel params. I think this is a bad idea; it doesn't defend against replay attacks at all, so if you authenticate to https://evilserver.example/, that server could turn around and impersonate you to https://yourjob.example/, which would be a Bad Thing. The certification needs to be bound to the channel, and to be on the safe side, it shouldn't be over data that either party has full control over. --dkg --gAJl20fXVoRt53hdoI2knqWCldRWP4TWc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTHh0zXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcgmwQAIOGP7koOM6Psg3ACZzWYUPO 7q7XvyFranhGun0fknuFhSAiWBYPOThft3ioy93GZYUJy9hJOIuzh47wXIz3BUWy O1uuJ7N6yefDPPwRdXfWJb0ebLeTmkjovBAa61Uwpa1i+sKyXvRp4qYnyoe0YFHx VnV9jYZXukxIqYJxNjq7puRfDfe614a/mr/IClKBBj1A4RGqv1C9125V55U5enCN RIqGCu2G9+KLPnImgQZZig6/iyYmu4rCBD7LtB3YxTcqMRu5qoGjp6Zvxd4f/gEd hncuFt2YrNuaolS+OspKIi/QsXUVQ3W/rSjhHK15C56loSczt6iIIhjHXHyVV8Lw 4utLultcFWQsmfHsJfU6t9QE1GME4+rwdtEwjTeQxBsIK+FF2wYSkNDk3LvvHd8c SmEIvvU50CJrh0zvC3kzDunU9ZPsABsZNPGOd1TC/+xZrbXhpzfRzv5OlZYJvcMM hc9+wZSLwdqwOHBuwfrLt39Y53tIFYB1pOxsw5Gfq3yd+WKhgMi7foQZ7O94WYjd 3agnVSQ8hfTGSu7SPjn1BKcXGeNI5KewhZHofKbaWkvNwDbZ59qX1Gni4UdVxJdN GR4uSxTrLOG9tAoWSANS67x8NT91o+n3JsVIStO8X9GKMZT7SjDyFMbDREo2yJ5H xdzhzT0lNw+9j2/RHpb5 =NM4x -----END PGP SIGNATURE----- --gAJl20fXVoRt53hdoI2knqWCldRWP4TWc-- From nobody Mon Mar 10 13:32:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365B01A0495 for ; Mon, 10 Mar 2014 13:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXaIh0Ya6d0y for ; Mon, 10 Mar 2014 13:32:10 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id D29541A024B for ; Mon, 10 Mar 2014 13:32:10 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 614B02856E; Mon, 10 Mar 2014 20:32:05 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 4E43428565; Mon, 10 Mar 2014 20:32:05 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 1AF9180047; Mon, 10 Mar 2014 20:32:05 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.104]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 10 Mar 2014 16:32:04 -0400 From: "Salz, Rich" To: Daniel Kahn Gillmor , Bill Frantz Date: Mon, 10 Mar 2014 16:32:03 -0400 Thread-Topic: [TLS] Renegotiation and client authentication Thread-Index: Ac88nWrXAzvDjgHkTHyJS5pPobryuwAAZ4ug Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D5001@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AB37C@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D4FD8@USMBX1.msg.corp.akamai.com> <531E1D33.20601@fifthhorseman.net> In-Reply-To: <531E1D33.20601@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/c3vt5srgYvAY2UMb0sCksNAyD3E Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 20:32:12 -0000 PiBJIHRoaW5rIHRoaXMgaXMgYSBiYWQgaWRlYTsgaXQgZG9lc24ndCBkZWZlbmQgYWdhaW5zdCBy ZXBsYXkgYXR0YWNrcyBhdCBhbGwsIHNvIGlmIHlvdSBhdXRoZW50aWNhdGUgdG8gaHR0cHM6Ly9l dmlsc2VydmVyLmV4YW1wbGUvLCB0aGF0IHNlcnZlciBjb3VsZCB0dXJuIGFyb3VuZCBhbmQgaW1w ZXJzb25hdGUgeW91IHRvIGh0dHBzOi8veW91cmpvYi5leGFtcGxlLywgd2hpY2ggd291bGQgYmUg YSBCYWQgVGhpbmcuDQoNCkhtLiAgT25seSBpZiBldmlsc2VydmVyLmdvdiB3YXMgYWJsZSB0byBz ZW5kIHlvdSB0aGUgZXhhY3Qgc2FtZSBjaGFsbGVuZ2UgdGhhdCB5b3Vyam9iLmNvbSB3b3VsZCBi ZSBzZW5kaW5nIHlvdS4gSSBzdXBwb3NlIHNvLiAgU28gdGhlIGNoYWxsZW5nZSBjb3VsZCBiZSBh IG5vbmNlIGhhc2hlZCB3aXRoIHRoZSBwcmUtbWFzdGVyIHNlY3JldCwgd2hpY2ggaXMgdGhlbiBz aWduZWQuICBCdXQgdGhpcyBpcyBhbHNvIG9mZiB0aGUgdG9wIG9mIG15IGhlYWQuICBUaGUgY29u Y2VwdCwgIndobyBhcmUgeW91IiBzZXBhcmF0ZSBmcm9tIGdlbmVyYWwgcmVuZWdvdGlhdGlvbiwg c2VlbXMgbGlrZSBhIGdvb2Qgb25lIHRvIG1lLg0KDQoJL3IkDQoNCi0tICANClByaW5jaXBhbCBT ZWN1cml0eSBFbmdpbmVlcg0KQWthbWFpIFRlY2hub2xvZ3kNCkNhbWJyaWRnZSwgTUENCg0K From nobody Mon Mar 10 14:30:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963981A04E9 for ; Mon, 10 Mar 2014 14:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ACSuGcJ-qLwb for ; Mon, 10 Mar 2014 14:30:05 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 38CB31A0146 for ; Mon, 10 Mar 2014 14:30:04 -0700 (PDT) Received: from [173.75.83.129] (helo=Williams-MacBook-Pro.local) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WN7lm-0001To-7Q; Mon, 10 Mar 2014 17:29:58 -0400 Date: Mon, 10 Mar 2014 14:29:57 -0700 From: Bill Frantz To: "Salz, Rich" X-Priority: 3 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D4FD8@USMBX1.msg.corp.akamai.com> 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec791926ef87617cbce5ccc43966e1421575350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.129 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UCNNNahryIjd4IumAb8qzIA4OnU Cc: tls@ietf.org Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Mar 2014 21:30:10 -0000 On 3/10/14 at 1:03 PM, rsalz@akamai.com (Salz, Rich) wrote: >Sever sends a challenge, client signs it. No need to tie the=20 >proof of possession to the channel, since we're explicitly NOT=20 >renegotiating any of the channel params. Given the number of attacks on the CA system*, I was looking for=20 a second check that there was no MITM. Including channel binding=20 would be cheap and easy. It would also occur in many cases=20 before really important secrets were exchanged. Of course checking for MITM would make deep inspection firewalls=20 harder. But that might be a good thing. Cheers - Bill * The coding errors revealed in iOS and GNUTLS, The number of=20 dead CAs still accepted by major browsers, the susceptibility of=20 CAs to legal action, are just some of the vulnerabilities in the=20 current system. ----------------------------------------------------------------------- Bill Frantz |Security, like correctness, is| Periwinkle (408)356-8506 |not an add-on feature. - Attr-| 16345=20 Englewood Ave www.pwpconsult.com |ibuted to Andrew Tanenbaum | Los Gatos,=20 CA 95032 From nobody Mon Mar 10 23:24:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5611A063E for ; Mon, 10 Mar 2014 23:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHhbe6b89_3h for ; Mon, 10 Mar 2014 23:24:45 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id C43751A0641 for ; Mon, 10 Mar 2014 23:24:44 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id w62so9750931wes.0 for ; Mon, 10 Mar 2014 23:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gmeWWghLFyrdERPqY9W07k7QG6c9KYG0N/X+UuO3jzI=; b=ebHAqpqCGbfdM0jJyI2tnnRhyZyFba94mSfvSZ/Ht9neeEiWB2qPO+/6QYnDtZgZiZ 7lNSEOhw1NO2hWdclWH0BuimJbTqd3D32/JnMwMy9vvURBbhxpoIWRWFoePn6FpBhnGx BGLvcrIoJSIAKL6kLwBJoexB0He5g9+nOs18MgbL+C25+FJtfCndXWlbYT+Ksu1Yt0Vu X0gaBfXGWmN63mN/qGVIUqZN+FhCEKRXvHbz7O4qeVnGt2Zt2YxRL+wVoERUweAGDtRp S9jTuSQBFzGcw8c1o+s72j2QougNJMbxbHOOqKDR9GugxrAgj6DMwi276od7fS+RCDtp vNsw== MIME-Version: 1.0 X-Received: by 10.180.149.206 with SMTP id uc14mr1589590wib.44.1394519078778; Mon, 10 Mar 2014 23:24:38 -0700 (PDT) Received: by 10.194.89.1 with HTTP; Mon, 10 Mar 2014 23:24:38 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D4FD8@USMBX1.msg.corp.akamai.com> Date: Tue, 11 Mar 2014 08:24:38 +0200 Message-ID: From: Yoav Nir To: Bill Frantz Content-Type: multipart/alternative; boundary=001a11c3800852bcd304f44ec6ca Archived-At: http://mailarchive.ietf.org/arch/msg/tls/h09bOGIlRI1kDQlsULD7xgKgGm0 Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Mar 2014 06:24:48 -0000 --001a11c3800852bcd304f44ec6ca Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 10, 2014 at 11:29 PM, Bill Frantz wrote: > On 3/10/14 at 1:03 PM, rsalz@akamai.com (Salz, Rich) wrote: > > Sever sends a challenge, client signs it. No need to tie the proof of >> possession to the channel, since we're explicitly NOT renegotiating any of >> the channel params. >> > > Given the number of attacks on the CA system*, I was looking for a second > check that there was no MITM. Including channel binding would be cheap and > easy. It would also occur in many cases before really important secrets > were exchanged. > > Of course checking for MITM would make deep inspection firewalls harder. > But that might be a good thing. > Deep inspection firewalls are entirely disabled by client certificates. This would not be so if client certificate authentication was moved to the HTTP layer rather than the TLS layer, but for now, such firewalls can either allow such connections to pass uninspected or block them. Yoav --001a11c3800852bcd304f44ec6ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 10, 2014 at 11:29 PM, Bill Frantz <= ;frantz@pwpconsu= lt.com> wrote:
On 3/10/14 at 1:03 PM, rsalz@akamai.com (Salz= , Rich) wrote:

Sever sends a challenge, client signs it. =A0No need to tie the proof of po= ssession to the channel, since we're explicitly NOT renegotiating any o= f the =A0channel params.

Given the number of attacks on the CA system*, I was looking for a second c= heck that there was no MITM. Including channel binding would be cheap and e= asy. It would also occur in many cases before really important secrets were= exchanged.

Of course checking for MITM would make deep inspection firewalls harder. Bu= t that might be a good thing.

Deep insp= ection firewalls are entirely disabled by client certificates. This would n= ot be so if client certificate authentication was moved=A0 to the HTTP laye= r rather than the TLS layer, but for now, such firewalls can either allow s= uch connections to pass uninspected or block them.

Yoav

--001a11c3800852bcd304f44ec6ca-- From nobody Tue Mar 11 01:36:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88261A0381 for ; Tue, 11 Mar 2014 01:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 SpjLo4V1q4xd for ; Tue, 11 Mar 2014 01:36:18 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 465601A0369 for ; Tue, 11 Mar 2014 01:36:18 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2B8a95I021427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Mar 2014 04:36:09 -0400 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 s2B8a5Xx027850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 11 Mar 2014 04:36:07 -0400 Message-ID: <1394526965.25354.93.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "Salz, Rich" Date: Tue, 11 Mar 2014 09:36:05 +0100 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D5001@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AB37C@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D4FD8@USMBX1.msg.corp.akamai.com> <531E1D33.20601@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D5001@USMBX1.msg.corp.akamai.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.22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qcQysMNCgyCIrLvXaNWoU8hOYg0 Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and client authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Mar 2014 08:36:20 -0000 On Mon, 2014-03-10 at 16:32 -0400, Salz, Rich wrote: > > I think this is a bad idea; it doesn't defend against replay attacks > at all, so if you authenticate to https://evilserver.example/, that > server could turn around and impersonate you to > https://yourjob.example/, which would be a Bad Thing. > > Hm. Only if evilserver.gov was able to send you the exact same > challenge that yourjob.com would be sending you. I suppose so. That is trivial for evilserver to achieve. There is a reason that client authentication is tied to the channel and part of the key exchange. regards, Nikos From nobody Tue Mar 11 15:15:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBE61A063F for ; Tue, 11 Mar 2014 15:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_71=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2atsoM3jLRk for ; Tue, 11 Mar 2014 15:15:24 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A6FF21A0878 for ; Tue, 11 Mar 2014 15:15:14 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 45049F984; Tue, 11 Mar 2014 18:15:05 -0400 (EDT) Message-ID: <531F8ADF.3060002@fifthhorseman.net> Date: Tue, 11 Mar 2014 18:14:55 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: IETF TLS WG , ietf-ssh@NetBSD.org References: <9A043F3CF02CD34C8E74AC1594475C7372387C9E@uxcn10-6.UoA.auckland.ac.nz> <201403072318.SAA28740@Chip.Rodents-Montreal.ORG> <20140308102142.GA25856@roeckx.be> <42833.1394302378@eng-mail01.juniper.net> In-Reply-To: <42833.1394302378@eng-mail01.juniper.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hAgHuKgrHmI2tcAfN23JFTv8b2JR1ekqH" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZmKY1ucfBjW0QU9Nh2EpLt6IIvM Subject: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Mar 2014 22:15:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hAgHuKgrHmI2tcAfN23JFTv8b2JR1ekqH Content-Type: multipart/mixed; boundary="------------080208080801050603010503" This is a multi-part message in MIME format. --------------080208080801050603010503 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/08/2014 01:12 PM, Mark D. Baushke wrote: > You raise a good point. Folks with 'bc -l' should be able to verify the= > MODP groups. The k-bit MODP discrete-log moduli is formulated as the smallest safe-prime that meets the form: 2^k - 2^(k-64) - 1 + 2^64 * { [2^(k-130) pi] + N } where N is a positive integer. More colloquially, this is: 64 bits of 0xFF, followed by (k-128) bits of pi, followed by 64 more bits of 0xFF. I don't know why this sequence was selected. Does anyone have any pointers to reasons you might want the modulus structured this way? Given a bit-length k, The attached python program tests all integers N in sequence, stopping at the first safe-prime. For example: 0 dkg@alice:~$ python3 ./gen-modp.py 768 searching for 768-bit safe-prime modulus, starting at: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B FFFFFFFF FFFFFFFF added 0x248b6 * 2^64 (decimal: 149686 * 2^64) The prime is: 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 } FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 0 dkg@alice:~$ Thus far, I've used it to generate the moduli for these groups: * 768-bit (MODP 1) * 1024-bit (MODP 2) * 1536-bit (MODP 5) * 2048-bit (MODP 14) * 3072-bit (MODP 15) i haven't yet generated these (mainly due to time): * 4096-bit (MODP 16) * 6144-bit (MODP 17) * 8192-bit (MODP 18) Regards, --dkg --------------080208080801050603010503 Content-Type: text/x-python; name="gen-modp.py" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="gen-modp.py" #!/usr/bin/python # Author: Daniel Kahn Gillmor # Date: 2014-03-11 # derive p for the default groups in RFC 3526 and RFC 5996 # these RFCs use a particular approach to derive the prime modulus, # based only on the size of the prime desired, and on the digits of pi. # this code performs the same search pattern and verifies the result. # Usage:=20 # $ python3 gen-modp.py 1024 # this will generate the 1024-bit modulus found in RFC 5996. import sys import gmpy2 def breakup(s,k): '''return string s broken into chunks of size k''' return (s[0+n:k+n] for n in range(0,len(s),k)) def displayhex(mpz,stream): '''write an mpz to stream in the form preferred by the MODP RFC's''' h =3D hex(mpz)[2:].upper() # strip leading 0x linelen =3D 48 if len(h) =3D=3D 6144//4: linelen +=3D 8 # section 6 of RFC 3526 is unusually-formatted for x in breakup(h,linelen): for y in breakup(x,8): stream.write(" " + y) stream.write("\n") def t_pi(n): '''return an mpz containing the first n bits of pi''' gmpy2.get_context().precision=3Dn+1 return gmpy2.mpz(gmpy2.floor((gmpy2.mpz(1) << (n-2)) * gmpy2.cons= t_pi(n+1))) def checkanswer(bitsize,inc): '''Given a number of bits and an selected offset, verify that the expected result of the MODP modulus selection scheme is a safe prime. We're using probabilistic primality testing here, but leaning hard on the test, making sure it's expensive and much more thorough than the default tests used during selection. ''' one =3D gmpy2.mpz(1) val =3D (one << bitsize) - (one << (bitsize-64)) - one + \ ((one<<64)* (t_pi(bitsize - 128) + inc)) if not (gmpy2.is_prime(val, bitsize) and \ gmpy2.is_prime((val-1)//2,bitsize)): raise Exception("expensive primality tests contradicted "+\ "the cheap ones!") print("The prime is: 2^%d - 2^%d - 1 + 2^64 * { [2^%d pi] + %d }"%\ (bitsize, bitsize-64, bitsize-(64+66), inc)) displayhex(val, sys.stdout) def search(bitsize): '''search for a prime with bitsize bits, using the pattern establishe= d by the MODP RFC's. ''' bits =3D gmpy2.mpz(0xffffffffffffffff) # 64 bits of 0xff # the remaining bits of pi # 64 bits of 0xff # then count up until we find a prime base =3D (bits << (bitsize-64)) + (t_pi(bitsize-128) << 64) + bits print("searching for %d-bit safe-prime modulus, starting at:"%(bitsiz= e,)) displayhex(base,sys.stdout) inc =3D 1 # initial offset started to clear the middle bits for pi while not gmpy2.is_prime(base) \ or not gmpy2.is_prime((base-1)>>1): if (inc % 17) =3D=3D 1: sys.stdout.write("\radding 0x%x * 2^64"%(inc)) inc +=3D 1 base +=3D 2**64 sys.stdout.write("\radded 0x%x * 2^64 (decimal: %d * 2^64)\n"%\ (inc,inc)) return inc if sys.argv.__len__() > 1: target =3D int(sys.argv[1]) else: target =3D 768 inc =3D search(target) checkanswer(target,inc) --------------080208080801050603010503-- --hAgHuKgrHmI2tcAfN23JFTv8b2JR1ekqH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTH4rfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcEOoQAOhJcRyP/9gOVqGLdzU4NJ2C +oJL5QZO6YXRMHN3AAjmX3iA7ccVx2xCNf99+vrleh11kC7lagZ3yqN2ZjufOpUg 0Rd3lg3n4FiOfjksqP36D8gDfoRsZmQgLA7qS+MNd8W80o3j3DR3uoyNZgtEYdMK natwJnSx6gVm2FzeU3BAe+AVFJyjVEPj7AypjvbbI/C2qajlD27vh/d0Dj9CECCe SGNcfPBQICNL/Pqr0xZbC/JUfvJ0lviCQkU1eJ5OTExa5P+6cVLMdN3oEINr7C7C TO7twz3OQgCfDBEM8DOMSGBq+3O6L8dOjFPb734sNBnFYggeAdpRlBI1sRxo2r5m eNq87LCFpX5YrWgL6KEXwmHhyDED8jRigs9OhDink2pQsXx3hLAodSWAy7VSLj+g fPp0dIO3flKicoIyEzt7LYxr3/QGtFqpv0H0+gJ6OhNpWpGWzT0ZiAEIyx1QLGoN mi0b/WnMEqEX6AvEzdUU3QcucxMOiJFZXqZcsuoAtu6H8OUPElG8Prw9ygWuT8g1 4iKtScMbUzMcBUfXVRIQaFcY5L3X0/o0nbhGBvWiiDRBbVG0zQeLQoqQ1uwvcKN9 /1MFCOyAFrUxRj7TDQECzrvgYAmXoYc7Mk9RVKPbrHjzaRXG5LjvAvPDMebsnDqA 7zSjlCDJfAnFM7I7/kX4 =1yQN -----END PGP SIGNATURE----- --hAgHuKgrHmI2tcAfN23JFTv8b2JR1ekqH-- From nobody Tue Mar 11 15:49:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1596E1A085E for ; Tue, 11 Mar 2014 15:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 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, FROM_12LTRDOM=0.1, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwlHvHh4pAJm for ; Tue, 11 Mar 2014 15:49:08 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (agjbgdcfdbec.dreamhost.com [69.163.253.142]) by ietfa.amsl.com (Postfix) with ESMTP id E7EFC1A081E for ; Tue, 11 Mar 2014 15:49:07 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 44BF42005D907 for ; Tue, 11 Mar 2014 15:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=NTZ/uydIbMCwMteOaGCHTmv+jNY=; b=xW8DRDdzCf3 LkrOxBU6Acu+az/ZRrZRnHWgakMPOubPyqnGONpBtoJYduimqCE6Jpgurb9qqis5 mYpCAzNw7WlNr5+tmelegJ10lyRB7CFi4Rns0zhfQwYRjJ0/EjwesGaMCBF0x4yo fm1/Ed1EMIIrxvRPgkRFhy5SGzmHrxkU= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id ED0022005D902 for ; Tue, 11 Mar 2014 15:49:01 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t61so10731618wes.3 for ; Tue, 11 Mar 2014 15:49:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=aLFWM46dRs6vR4Z9lfojgxqGyy1s1CBer88xX9ZpKrg=; b=aZmJfWOrTs/TYrIN0PzkGCokAUnOrviTa7d8rM5LgHYIsX2+LlQETnp7a87ffTB4eo sWynuIEOqDPHZxr7z0GxtrudKKlMplanl79jh+u8ZUCmN8Xuy2dai9mlr5oQhoC/EJpy bqfJpBUXGpgkfdLxhmAtbfylgB6i+xDDCryj07Xame1dQOwYV+SWTyULgL9kzKHthIpe ZS4q9PJxMbVC8/8LlBHDZtqTbEuJ7y9WUfRasORXLwcKTYoGOvQfKY7kxKDtJd89Crai 9nBCu0TL/o+YBYWn4VBus1RSMVX7B4diWShl0TROwrAyonLuIjbwFyCsq9yHHZ1ea196 d4zQ== MIME-Version: 1.0 X-Received: by 10.180.77.74 with SMTP id q10mr4954167wiw.39.1394578140849; Tue, 11 Mar 2014 15:49:00 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 15:49:00 -0700 (PDT) Date: Tue, 11 Mar 2014 17:49:00 -0500 Message-ID: From: Nico Williams To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pHhe7gFfItsUijmwholOdAy9bjk Subject: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Mar 2014 22:49:09 -0000 This is a big problem for anything that wants to do opportunistic TLS (e.g., MTAs, like Postfix). Shall I submit an I-D? With what handle? draft-williams-... or draft-tls-...? Nico -- From nobody Tue Mar 11 15:55:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDD81A088D for ; Tue, 11 Mar 2014 15:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnjmR_-FZ38M for ; Tue, 11 Mar 2014 15:55:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 564141A088C for ; Tue, 11 Mar 2014 15:55:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8D033BE3F for ; Tue, 11 Mar 2014 22:55:00 +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 CG+VDg7HZE0l for ; Tue, 11 Mar 2014 22:54:59 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.46.16.238]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 59C96BE20 for ; Tue, 11 Mar 2014 22:54:59 +0000 (GMT) Message-ID: <531F9443.1000002@cs.tcd.ie> Date: Tue, 11 Mar 2014 22:54:59 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3QlLhYFaLS01bW_0Bc6m6H4Ke3s Subject: [TLS] TLS chairing changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 22:55:08 -0000 Hiya, Now that the TLS WG has rechartered to work on TLS 1.3, I've been chatting with the chairs and we wanted to announce some adjustments intended to help that effort. Effective April 1st, Sean Turner will become a third TLS co-chair in order to free up Eric who will be a TLS 1.3 document editor. (Sean picked the date, it really means whenever he gets back from his post-AD vacation so it could be in a week or so:-) Eric will stay on as co-chair to help Sean get up to speed but the plan is for him to step down as chair around about IETF 90 in July. And Joe will continue chairing with Sean from then onwards. Many thanks to Joe and Eric for their ongoing efforts and thanks also to Sean for being willing to get back into the saddle for such an important WG so quickly. Cheers, S. From nobody Tue Mar 11 17:25:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D231A08A1 for ; Tue, 11 Mar 2014 17:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTvGAEiKOxvv for ; Tue, 11 Mar 2014 17:25:20 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF361A0896 for ; Tue, 11 Mar 2014 17:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1394583915; x=1426119915; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=PqX/Ryv0hh3BgYugDTtcwd5Mxw8zZZGb8225ZJ+eXgg=; b=PRNrnov+cD3O/VZ6HqiXiAVJ/kSrEcCcGC0xTlIM/UXCViXg2KDJYEkK jgJ+M/Yvp2+VWsnoyLu+v7O4UpCpM95vdbzRSBwuxBVaPg8WxWVFXpJ+D TzqKJojPEzPYVDp65P7tCzqkgfa15QxxwY3HRA7iy6QjrnXPDDThvTYEV c=; X-IronPort-AV: E=Sophos;i="4.97,634,1389697200"; d="scan'208";a="238959174" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Mar 2014 13:25:14 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Wed, 12 Mar 2014 13:25:13 +1300 From: Peter Gutmann To: "" , "ietf-ssh@netbsd.org" Thread-Topic: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] Thread-Index: Ac89iYieoDktMLvTRCu1CZHjC2IAVQ== Date: Wed, 12 Mar 2014 00:25:12 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C737238A20F@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VkLl9FSET0zCHWSJCF5L3rR4Yg0 Subject: Re: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 00:25:26 -0000 Daniel Kahn Gillmor writes:=0A= =0A= >More colloquially, this is: 64 bits of 0xFF, followed by (k-128) bits of p= i,=0A= >followed by 64 more bits of 0xFF. I don't know why this sequence was=0A= >selected. Does anyone have any pointers to reasons you might want the=0A= >modulus structured this way?=0A= =0A= The prime for this group was selected to have certain properties. The = high=0A= order 64 bits are forced to 1. This helps the classical remainder=0A= algorithm, because the trial quotient digit can always be taken as the = high=0A= order word of the dividend, possibly +1. The low order 64 bits are for= ced=0A= to 1. This helps the Montgomery-style remainder algorithms, because th= e=0A= multiplier digit can always be taken to be the low order word of the=0A= dividend. The middle bits are taken from the binary expansion of pi. = This=0A= guarantees that they are effectively random, while avoiding any suspici= on=0A= that the primes have secretly been selected to be weak.=0A= =0A= The prime is chosen to be a Sophie-Germain prime (i.e., (P-1)/2 is also= =0A= prime), to have the maximum strength against the square-root attack. T= he=0A= starting trial numbers were repeatedly incremented by 2^64 until suitab= le=0A= primes were located.=0A= =0A= Because this prime is congruent to 7 (mod 8), 2 is a quadratic residue.= =0A= All powers of 2 will also be quadratic residues. This prevents an oppon= ent=0A= from learning the low order bit of the Diffie-Hellman exponent. Using = 2 as=0A= a generator is efficient for some modular exponentiation algorithms. [= Note=0A= that 2 is technically not a generator in the number theory sense, becau= se=0A= it omits half of the possible residues mod P. From a cryptographic=0A= viewpoint, this is a virtue.]=0A= =0A= This is from an early Oakley draft draft-ietf-ipsec-isakmp-oakley-03.txt th= at=0A= references another Oakley draft draft-ietf-ipsec-oakley-01.txt which, howev= er,=0A= doesn't actually contain the text quoted above. So I guess the reference= =0A= would be [Citation needed ^ 2] or [Apocryphal ^ 2].=0A= =0A= (Oh, and if anyone feels like confirming the SHA-1 hashes of the primes I= =0A= posted last week....).=0A= =0A= Peter.=0A= From nobody Tue Mar 11 18:18:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDC91A08BA for ; Tue, 11 Mar 2014 18:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 zBifaMfmMK0n for ; Tue, 11 Mar 2014 18:18:28 -0700 (PDT) Received: from vsp4.ballou.se (vsp4.ballou.se [91.189.40.102]) by ietfa.amsl.com (Postfix) with SMTP id 478161A08C5 for ; Tue, 11 Mar 2014 18:18:27 -0700 (PDT) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp4.ballou.se (Halon Mail Gateway) with ESMTP; Wed, 12 Mar 2014 02:16:12 +0100 (CET) Received: from [192.168.0.195] (c-a2c1e555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.193.162]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 4EDF81E05E; Wed, 12 Mar 2014 02:18:19 +0100 (CET) Message-ID: <531FB5DC.1010001@streamsec.se> Date: Wed, 12 Mar 2014 02:18:20 +0100 From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , IETF TLS WG , ietf-ssh@NetBSD.org References: <9A043F3CF02CD34C8E74AC1594475C7372387C9E@uxcn10-6.UoA.auckland.ac.nz> <201403072318.SAA28740@Chip.Rodents-Montreal.ORG> <20140308102142.GA25856@roeckx.be> <42833.1394302378@eng-mail01.juniper.net> <531F8ADF.3060002@fifthhorseman.net> In-Reply-To: <531F8ADF.3060002@fifthhorseman.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/al1wg1DAJU23ULFv-N21ImehOwY Subject: Re: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list 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, 12 Mar 2014 01:18:30 -0000 On 2014-03-11 23:14, Daniel Kahn Gillmor wrote: > More colloquially, this is: 64 bits of 0xFF, followed by (k-128) bits of > pi, followed by 64 more bits of 0xFF. I don't know why this sequence > was selected. Does anyone have any pointers to reasons you might want > the modulus structured this way? - If the least significant word of the modulus equals 2^w-1, Montgomery reduction becomes more efficient. - If the most significant word of the modulus equals 2^w-1, school-book reduction and Barrett reduction becomes more efficient. - Pi usually plays the role of a "nothing-up-my-sleeve" value. If a random value had been chosen, there would have been no easy way to verify that a specially crafted value hadn't been chosen. For instance, it is possible to generate a prime, such that the discrete logarithm of selected smooth numbers becomes to known to the entity generating the prime, and that would make the discrete logarithm problem easier for that entity. > > i haven't yet generated these (mainly due to time): > > * 4096-bit (MODP 16) > * 6144-bit (MODP 17) > * 8192-bit (MODP 18) Python is likely too slow for this. Generating the 8192 bit prime takes a couple of hours on a contemporary PC using reasonably optimized native code. From nobody Tue Mar 11 19:22:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB98F1A08CE for ; Tue, 11 Mar 2014 19:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y37CJtpxYQur for ; Tue, 11 Mar 2014 19:22:08 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 0959F1A036B for ; Tue, 11 Mar 2014 19:22:07 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CB65B47489; Wed, 12 Mar 2014 02:22:01 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id BE81E47426; Wed, 12 Mar 2014 02:22:01 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id B90CF80044; Wed, 12 Mar 2014 02:22:01 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.104]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Tue, 11 Mar 2014 22:22:01 -0400 From: "Salz, Rich" To: Stephen Farrell , "tls@ietf.org" Date: Tue, 11 Mar 2014 22:22:00 -0400 Thread-Topic: [TLS] TLS chairing changes Thread-Index: Ac89fPNVHHtkzDjLSZSuTsbwdCQ/6AAHLeTQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D54FD@USMBX1.msg.corp.akamai.com> References: <531F9443.1000002@cs.tcd.ie> In-Reply-To: <531F9443.1000002@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ns7zSk0-Q8T-n62QohohNCsQqbA Subject: Re: [TLS] TLS chairing changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 02:22:12 -0000 > Many thanks to Joe and Eric for their ongoing efforts and thanks also to = Sean for being willing to get back > into the saddle for such an important WG so quickly. Hear, hear! And interesting to hear that Sean is such a glutton for punishment. :) /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Tue Mar 11 20:56:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E97D1A04F6 for ; Tue, 11 Mar 2014 20:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAtgzXUdqiBh for ; Tue, 11 Mar 2014 20:56:20 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 63B901A03AC for ; Tue, 11 Mar 2014 20:56:20 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id v1so5077590yhn.28 for ; Tue, 11 Mar 2014 20:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2JpMOyQ5+ksDdHdx4VjwDgb/w1a52n75ocicKPPxLqY=; b=ysQLnopVlb56+LeAEvOuD7NtrlkBEsxQ2LQ6kJKrNr9cIFsA9VWEsxnYbMuM9bKd2r WMCi2QXLAKO4ZO8FDFLBWegAsLo+LQdRMkvFWLtux+shlsyHI19DM6rij8xhb1lE8/EY o/rZjB6Ifqe3MR/07dvK0ZUpPgofbdoGKZYaLALpeLumSECJEFs0HMJDJF99BrpIlnPC w/VQMypx9EJZoJMELQ2sAoTOWU3FvXnr8ej2MygMvyuHoLNRHgdoMJRnPceajdUHVjxI MV/1gM/rb91YMXIJEr5/flT5d/Nr2inLPG35sr1PSczbCisRV/joAdawCufNrPsn/ziv U2TQ== MIME-Version: 1.0 X-Received: by 10.236.139.70 with SMTP id b46mr14031026yhj.63.1394596574379; Tue, 11 Mar 2014 20:56:14 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Tue, 11 Mar 2014 20:56:14 -0700 (PDT) In-Reply-To: <531FB5DC.1010001@streamsec.se> References: <9A043F3CF02CD34C8E74AC1594475C7372387C9E@uxcn10-6.UoA.auckland.ac.nz> <201403072318.SAA28740@Chip.Rodents-Montreal.ORG> <20140308102142.GA25856@roeckx.be> <42833.1394302378@eng-mail01.juniper.net> <531F8ADF.3060002@fifthhorseman.net> <531FB5DC.1010001@streamsec.se> Date: Tue, 11 Mar 2014 20:56:14 -0700 Message-ID: From: Watson Ladd To: henrick@streamsec.se Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sFSEnVgvD0qVmZDZ1-S7r7_gOng Cc: ietf-ssh@netbsd.org, IETF TLS WG Subject: Re: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 03:56:22 -0000 On Tue, Mar 11, 2014 at 6:18 PM, Henrick Hellstr=C3=B6m wrote: > > On 2014-03-11 23:14, Daniel Kahn Gillmor wrote: >> >> More colloquially, this is: 64 bits of 0xFF, followed by (k-128) bits of >> pi, followed by 64 more bits of 0xFF. I don't know why this sequence >> was selected. Does anyone have any pointers to reasons you might want >> the modulus structured this way? > > > - If the least significant word of the modulus equals 2^w-1, Montgomery r= eduction becomes more efficient. > - If the most significant word of the modulus equals 2^w-1, school-book r= eduction and Barrett reduction becomes more efficient. > - Pi usually plays the role of a "nothing-up-my-sleeve" value. If a rando= m value had been chosen, there would have been no easy way to verify that a= specially crafted value hadn't been chosen. For instance, it is possible t= o generate a prime, such that the discrete logarithm of selected smooth num= bers becomes to known to the entity generating the prime, and that would ma= ke the discrete logarithm problem easier for that entity. > > >> >> i haven't yet generated these (mainly due to time): >> >> * 4096-bit (MODP 16) >> * 6144-bit (MODP 17) >> * 8192-bit (MODP 18) > > > Python is likely too slow for this. Generating the 8192 bit prime takes a= couple of hours on a contemporary PC using reasonably optimized native cod= e. A few hours? The trick is to sieve: the numbers for various N are in an arithmetic progression with a=3D2^64. As a result, you can determine which N are possible because of small prime obstructions, thus decreasing the amount of work to be done. In fact, I think your first N is entirely determined by considerations modulo the primes less than 100. Secondly look at (p-1)/2=3Dq instead. If this is known prime determining if 2*q+1 is prime is quick using Pocklington's Theorem: you don't need to do the extensive primality testing. Sincerely, Watson Ladd > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Mar 12 02:12:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1B41A0934 for ; Wed, 12 Mar 2014 02:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdaC8fecv9Ps for ; Wed, 12 Mar 2014 02:12:29 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 67B081A092F for ; Wed, 12 Mar 2014 02:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=NN/aUzy0vsF2GrAuefHIfieZygXdFwylM8CMIdjFvNI=; b=fGNqYs9t3gKoI/u7q7ERnCB5cv+RpYhJ4ldnHsXCO/GPj24GkY7q/Az73TIEvi0jd+pnxRJH6zJIsVMmY0t/PrHU2M3eUqJtjFr9Shq3HZG6nHx1enfnNduxLWJxaPXycPa4TzIlhg5zuzIOOaKhT7dHcG5UJgpoWPDZEDem7SY=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WNfDE-0004vi-UU for tls@ietf.org; Wed, 12 Mar 2014 10:12:34 +0100 Message-ID: <532024EF.4060607@polarssl.org> Date: Wed, 12 Mar 2014 10:12:15 +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 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MZnE-Id4l0El66w6Ak_1NeeGExA Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 09:12:30 -0000 Hi, On 03/11/2014 11:49 PM, Nico Williams wrote: > This is a big problem for anything that wants to do opportunistic TLS > (e.g., MTAs, like Postfix). > Sorry if I'm missing something obvious, but why would ECDH_anon be a requirement for opportunistic TLS? Can't we just use certificates and not validate them? Or are you rather interested in the performance gain of ECDH_anon over authenticated and forward-secure key exchanges? Manuel. From nobody Wed Mar 12 02:53:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623E01A093E for ; Wed, 12 Mar 2014 02:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 AGPPcJo8i0SX for ; Wed, 12 Mar 2014 02:53:38 -0700 (PDT) Received: from vsp4.ballou.se (vsp4.ballou.se [91.189.40.102]) by ietfa.amsl.com (Postfix) with SMTP id A93A71A0939 for ; Wed, 12 Mar 2014 02:53:34 -0700 (PDT) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp4.ballou.se (Halon Mail Gateway) with ESMTP; Wed, 12 Mar 2014 10:51:18 +0100 (CET) Received: from [192.168.0.195] (c-a2c1e555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.193.162]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 3ED6D1E061; Wed, 12 Mar 2014 10:53:26 +0100 (CET) Message-ID: <53202E8D.9090403@streamsec.se> Date: Wed, 12 Mar 2014 10:53:17 +0100 From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Watson Ladd References: <9A043F3CF02CD34C8E74AC1594475C7372387C9E@uxcn10-6.UoA.auckland.ac.nz> <201403072318.SAA28740@Chip.Rodents-Montreal.ORG> <20140308102142.GA25856@roeckx.be> <42833.1394302378@eng-mail01.juniper.net> <531F8ADF.3060002@fifthhorseman.net> <531FB5DC.1010001@streamsec.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G8yNf1nLb6lBpHjAJzBn8j0Gs0Q Cc: ietf-ssh@netbsd.org, IETF TLS WG Subject: Re: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list 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, 12 Mar 2014 09:53:43 -0000 On 2014-03-12 04:56, Watson Ladd wrote: > A few hours? The trick is to sieve: the numbers for various N are in > an arithmetic progression with a=2^64. As a result, you can determine > which N are possible because of small prime obstructions, thus > decreasing the amount of work to be done. In fact, I think your first > N is entirely determined by considerations modulo the primes less than > 100. > > Secondly look at (p-1)/2=q instead. If this is known prime determining > if 2*q+1 is prime is quick using Pocklington's Theorem: you don't need > to do the extensive primality testing. Exactly, have you tried this? For the 8192 bit prime, you are to eliminate 4,743,158 candidates. Suppose: - you are using a double sieve on both primes that eliminates all but 0.6-0.7% of the candidates, - you are doing the Fermat test of the Pocklington criterion first, and this eliminates all but 1-2% of the remaining candidates, then this means your search will still be dominated by some 300,000 modular exponentiations with a 8192 bit modulus and with 8191 bit exponents. Let's say a reasonably optimized implementation performs such an exponentiation in 400ms on a contemporary PC. This leaves you with an expected running time of 20 min. From nobody Wed Mar 12 05:59:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CAA1A0984 for ; Wed, 12 Mar 2014 05:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3] 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 MtLEI2uB6Nxd for ; Wed, 12 Mar 2014 05:59:51 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5467F1A096E for ; Wed, 12 Mar 2014 05:59:51 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 2E95FF984; Wed, 12 Mar 2014 08:59:43 -0400 (EDT) Message-ID: <53205A3F.5080802@fifthhorseman.net> Date: Wed, 12 Mar 2014 08:59:43 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= , tls@ietf.org References: <532024EF.4060607@polarssl.org> In-Reply-To: <532024EF.4060607@polarssl.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Cre2aXLRPQL9oLA2E3xmhL4BKLdg7JFtE" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YFMrByR8PSpKnvWL9yDjuBQ54Tk Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 12:59:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Cre2aXLRPQL9oLA2E3xmhL4BKLdg7JFtE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/12/2014 05:12 AM, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > Sorry if I'm missing something obvious, but why would ECDH_anon be a re= quirement > for opportunistic TLS? Can't we just use certificates and not validate = them? using certificates and expecting the peer to not validate them has a couple downsides: 0) either the software or the admin must manually provision the certificate for the server; this means making decisions about questions that don't necessarily have any good answers, which is not a situation you want your users to be in. Servers operating in a pool now need to have some sort of secret key distribution mechanism, for example. 1) as peers start using TOFU-like mechanisms (which cannot be controlled or even necessarily observed by the server itself, the choices made in (0) become relevant -- want to rotate your key? want to deploy a "real" certificate? want to deploy a certificate issued by your private CA? all of a sudden your server's identity has changed from one explicit identity to another. In the anon case, you can have simple, automatic, configuration-less deployment that makes no claims of identity at all. > Or are you rather interested in the performance gain of ECDH_anon over > authenticated and forward-secure key exchanges? the performance difference on the server side is one RSA or ECDSA signature per connection; i don't think this is likely to be a large factor, though i guess it depends on the key size. --dkg --Cre2aXLRPQL9oLA2E3xmhL4BKLdg7JFtE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTIFo/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcw4wP/3B12p9uD45NMmGldlwRMd2C VLv09lD+OP2Mb9k9/RPHfaBK7AZ8RQYwmlCbG2FN+2sY8RS5vY9w1w9ng10iJ9e1 L64NZSiX58gwCcEbNI4Ko61qQvqgY+yrn1Wk3+GIeODiUGI0A8F6IFY7/GTxlQS0 wBf30xbkwQ339Cefz43lTBIISW0ni0I0j7IfA9zM7GuhMBdk/idtTzYtTk+hu5/H odvAWZWcTX+k7KcazAfrtLWMze1H0HL0ael4O0gixuWLw9nKtkZQj1NgzQ9DROPF 9bCEj9mKyPpJVSTKq46XG0xlGRELaFE1fMFBhBo0VjdzT/mO2XUmvLuFG1JGrD+K +2u1o8klXH/mvhKzQTRmEVwSszfRebpPhWTmyl3BaIcS5f8iIHKvST1TN641cTmd 7fhpxlRXqazC0GKbN+nFlbAw4RNYvtd2Z8OnKVrjHi9dE383JIEzJzjplAzQL0o1 W3hBNxmkLmgKm/JMC/MZ0P7I5yKrRPpTGaZG6fAUr5P7xpMYLkroJrW7iJE10wXq JrGijhQ5ubu9++9xE76hGt2b6Kpm9fmT9uhlyw4zYXCh1qSbpvnw3zwuOe3pcFV+ C2Bj3aaSd5HEjxjeZGBLBKMjLjEWxI9O+GZDorDlkF1mgVHldhKTJdxF3T/B9Tps xRhF6t5VUllXL/6jtvEC =6dqA -----END PGP SIGNATURE----- --Cre2aXLRPQL9oLA2E3xmhL4BKLdg7JFtE-- From nobody Wed Mar 12 06:22:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3041A0980 for ; Wed, 12 Mar 2014 06:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 4AD8AhMrNyjt for ; Wed, 12 Mar 2014 06:22:46 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id E0D7C1A0421 for ; Wed, 12 Mar 2014 06:22:45 -0700 (PDT) Received: from [10.69.242.136] (94.197.121.41.threembb.co.uk [94.197.121.41]) by entima.net (Postfix) with ESMTPSA id A640460B8E for ; Wed, 12 Mar 2014 13:22:38 +0000 (GMT) User-Agent: K-9 Mail for Android In-Reply-To: <53205A3F.5080802@fifthhorseman.net> References: <532024EF.4060607@polarssl.org> <53205A3F.5080802@fifthhorseman.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Wed, 12 Mar 2014 13:22:32 +0000 To: tls@ietf.org Message-ID: <2643d802-f33b-4caf-b5e1-4df42d59814e@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uMktIepnz98Bb9wUFVGY0LM_UXI Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 13:22:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 12 March 2014 12:59:43 GMT+00:00, Daniel Kahn Gillmor wrote: >using certificates and expecting the peer to not validate them has a >couple downsides: > 0) [certificate provisioning] > 1) [TOFU complications] And an upside: An attacker in a position to MITM in TLSv1.2 would be in a position to see *_anon suites offered: and therefore heuristically guess what the peers will choose and whether an active MITM attack would likely be detected or not. That would be bad: I think we'll want to conceal that data if possible so that an attacker can't easily distinguish between opportunistic connections they'd succeed silently on (and restrict their MITM to that case, silently decrypting without tripping any warnings and staying under the radar), and authenticated connections in which MITM shenanigans would raise very loud alarm bells. Let's try to keep the "lasers" invisible to third parties, if we can? Of course if we keep this in mind for TLSv1.3 and the Hellos are encrypted in that version, problem hopefully solved, although the size of the Hello exchange might provide a side channel revealing whether certs were exchanged. Thoughts? - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.0.9 iQI3BAEBCgAhBQJTIF+YGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6jAYP/3djv/eTRe7dSzJem8jFYhpwM/PJKq+ZKLx6Kf2RGOrD0QD4r1WS zgYEPF6rK2tm8s7G4P16emKzV0/L4rk0jE3yfPm8q3+7ce3VkIqxWMiXw18gNK9q EPcSuQVm1rlLovjvXTqzWL3LVmIQpm4hpGGJ02DjJXcAl5DKyGhTG5pCGQVoyHSA 3zw1q9lD2GcvAh5d5AwXWbbxMmtE4Z5p0GWGq9xGFnYA8CSMU8QvrGhz9C071z97 /HTOZ7YpeiVcXWa4ilQ1PclGe3zJySkLgJwy4PMwOslslITb5HDYi+b7yo+7+L9t jkLIVKwfX3rI1QZavJRSVCVw49i9f/0+pYwMdZHvcM9y9BHLGOeqZw20RUxaQX7K vLs0cKvMU5JQDbWO4ZJVVZX8Q6U9ngghdD9qnetyfpQuQpihWQYsp14hiabKsFp0 UaNzeQTop7IM7Y0MFQagFbHRDPO6DK+2t+xtjiTmDW5LuxH4cpbySksum6APeYe+ 8dS6wRVosqLHotAoqdIckCkHINzfuFVM8fqRhkofGywAjuXmoC88lq50N5D+guc1 pjO8i4VP5j//nUZ011v4aGrJtV2yxh9ytluhz/fWlNNGcF0OsPliF2KwkxjbS4jd 0rV0c2n321NWyAphynLWF/g1gpC8gHD+KJ6r3e03AQh6nI/0ZTV/WU3s =S255 -----END PGP SIGNATURE----- From nobody Wed Mar 12 06:35:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824B71A0989 for ; Wed, 12 Mar 2014 06:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYZJucL50cOa for ; Wed, 12 Mar 2014 06:35:21 -0700 (PDT) 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 08BCE1A096E for ; Wed, 12 Mar 2014 06:35:20 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ks9so4098758vcb.41 for ; Wed, 12 Mar 2014 06:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hdMDNwtveNQZcyjFV+hSUNjASfUYszBOOu5Ykz/6IHc=; b=T3K2ZLy2nUaTjx0RiT9S52+zTXMRauvIbPvJxKAjUN3hBnkp04+mezkvLq5sGnpjDI uylcSMdoSdM79WIB2Upjs6n4UDjb2wH2oE5YSPPupNyGZq8aD6iMJ0veubLY/pishoYG Ra/KZZpD1Axfq8+PkiNhAyyws8rbQAPF5kHFKP7DzPKOazdO0krh+WnYz9iyHPEcKk2C bkfo59vGdRnhTjUiTO2KjSt2fzXDzj/yg4gs+BroV+eZ+VZC0rmRYFPsQCUTA78ER9Ir Q3wyVG5Rwbdwv9OrjNAwMkJXlJHo3ci21HibPYVhqY3s1dq/+xbEefgUrQ4+hRDOgrrZ AXsQ== X-Received: by 10.52.126.107 with SMTP id mx11mr263564vdb.41.1394631314685; Wed, 12 Mar 2014 06:35:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.3.72 with HTTP; Wed, 12 Mar 2014 06:34:34 -0700 (PDT) In-Reply-To: <2643d802-f33b-4caf-b5e1-4df42d59814e@email.android.com> References: <532024EF.4060607@polarssl.org> <53205A3F.5080802@fifthhorseman.net> <2643d802-f33b-4caf-b5e1-4df42d59814e@email.android.com> From: Alexandre Anzala-Yamajako Date: Wed, 12 Mar 2014 14:34:34 +0100 Message-ID: To: Alyssa Rowan Content-Type: multipart/alternative; boundary=bcaec520f6891ac6d604f468e8d7 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZuqPzblE5EyR4S8-zI5pp4YPwd0 Cc: tls@ietf.org Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 13:35:22 -0000 --bcaec520f6891ac6d604f468e8d7 Content-Type: text/plain; charset=ISO-8859-1 Just out of curisoity, is anyone aware of scenarios where people chose *_anon suites to save on the bandwidth of sending certificates ? -- Alexandre Anzala-Yamajako --bcaec520f6891ac6d604f468e8d7 Content-Type: text/html; charset=ISO-8859-1
Just out of curisoity, is anyone aware of scenarios where people chose *_anon suites to save on the bandwidth of sending certificates ?


--
Alexandre Anzala-Yamajako


--bcaec520f6891ac6d604f468e8d7-- From nobody Wed Mar 12 07:08:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5BF1A0421 for ; Wed, 12 Mar 2014 07:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHChnqmDyV6t for ; Wed, 12 Mar 2014 07:08:18 -0700 (PDT) Received: from bacon.lysator.liu.se (vindbrygga.lysator.liu.se [IPv6:2001:6b0:17:f0a0::de]) by ietfa.amsl.com (Postfix) with ESMTP id 185E31A06B2 for ; Wed, 12 Mar 2014 07:08:17 -0700 (PDT) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s2CE86Fh028845; Wed, 12 Mar 2014 15:08:06 +0100 (MET) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s2CE850C028844; Wed, 12 Mar 2014 15:08:05 +0100 (MET) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: henrick@streamsec.se References: <9A043F3CF02CD34C8E74AC1594475C7372387C9E@uxcn10-6.UoA.auckland.ac.nz> <201403072318.SAA28740@Chip.Rodents-Montreal.ORG> <20140308102142.GA25856@roeckx.be> <42833.1394302378@eng-mail01.juniper.net> <531F8ADF.3060002@fifthhorseman.net> <531FB5DC.1010001@streamsec.se> <53202E8D.9090403@streamsec.se> Date: Wed, 12 Mar 2014 15:08:05 +0100 In-Reply-To: <53202E8D.9090403@streamsec.se> ("Henrick =?iso-8859-1?Q?Hell?= =?iso-8859-1?Q?str=F6m=22's?= message of "Wed, 12 Mar 2014 10:53:17 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/E53mutbyiUBLarZSF1EqiW9e9Bk Cc: ietf-ssh@netbsd.org, IETF TLS WG Subject: Re: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 14:08:23 -0000 Henrick Hellstrm writes: >> Secondly look at (p-1)/2=q instead. If this is known prime determining >> if 2*q+1 is prime is quick using Pocklington's Theorem: you don't need >> to do the extensive primality testing. > > Exactly, have you tried this? I couldn't resist, so I have now tried that. Below is a lite program to search for strong primes of the given form. It generates a 4096-bit prime in about 30s on my office machine (an intel core i5). I haven't had the patience to let it complete search for the 8192 prime. Some comments: 1. This is a quick hack, not thoroughly tested or profiled, etc. 2. It may be advantageous to use an even larger prime table for the sieving. Current code overflows somewhere if it is made substantially larger, though. Generating the prime table is more or less instantaneous. 3. The 8192-bit prime definitely seems a bit expensive to generate. 4. I let the pari/gp compute the pi approximation for me. The program could be made more self-contained if one adds some suitable function for computing pi to arbitrary precision, but I'm not really familiar with that problem. Regards, /Niels /* Copyright (C) 2014 Niels Mller This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see . */ #include #include #include #include #include #include static void * xalloc (size_t size) { void *p = malloc (size); if (!p) { fprintf (stderr, "Memory exhausted.\n"); abort(); } return p; } static void * xrealloc (void *p, size_t size) { p = realloc (p, size); if (!p) { fprintf (stderr, "Memory exhausted.\n"); abort(); } return p; } struct prime_info { uint32_t p; /* An odd prime. */ uint32_t inv; /* p^{-1} mod 2^32 */ uint32_t limit; /* floor ((2^32-1) / p) */ }; static struct prime_info *primes; static unsigned nprimes; #define DIVISIBLE_P(x, i) ((x) * primes[i].inv <= primes[i].limit) static uint32_t binvert(uint32_t a) { unsigned char tab[8] = { 1, 11, 13, 7, 9, 3, 5, 15 }; uint32_t x = tab[(a >> 1) & 7]; /* 4-bit inverse */ x = 2*x - a*x*x; /* 8 bits */ x = 2*x - a*x*x; /* 16 bits */ x = 2*x - a*x*x; /* 32 bits */ assert (a*x == 1); return x; } static void init_table (unsigned limit) { /* Number of odd numbers in the range 3 <= j < limit */ unsigned sieve_size = limit/2-1; char *sieve = xalloc (sieve_size); unsigned table_size = 0; unsigned i; primes = NULL; nprimes = 0; memset (sieve, 1, sieve_size); for (i = 0; i < sieve_size; i++) { unsigned p = 3 + 2*i; unsigned j; if (sieve[i]) { /* fprintf (stderr, "%u\n", p); */ if (nprimes <= table_size) { table_size = 50 + 3*table_size/2; primes = realloc (primes, table_size); } primes[nprimes].p = p; primes[nprimes].inv = binvert(p); primes[nprimes].limit = (~(uint32_t) 0) / p; nprimes++; } /* Clear elements corrsponding to p^2, (p+2)^p, ... */ for (j = (p*p-3)/2; j < sieve_size; j += p) sieve[j] = 0; } free (sieve); } /* Find the first strong prime in the sequence start + k step */ void next_strong_prime(mpz_t r, const mpz_t start, const mpz_t step) { mpz_t t, q, p, pm1, h; uint32_t *qmod = xalloc (nprimes * sizeof(*qmod)); uint32_t *hmod = xalloc (nprimes * sizeof(*hmod)); unsigned i; mpz_inits (t, q, p, pm1, h, NULL); /* Some other variants are possible, but exclude them, for simplicity */ assert (mpz_odd_p (start)); assert (mpz_even_p (step)); mpz_gcd (t, start, step); assert (mpz_cmp_ui (t, 1) == 0); mpz_sub_ui (q, start, 1); mpz_fdiv_q_2exp (q, q, 1); mpz_fdiv_q_2exp (h, step, 1); for (i = 0; i < nprimes; i++) hmod[i] = mpz_fdiv_ui (h, primes[i].p); for (;;) { /* New q, recompute qmod */ for (i = 0; i < nprimes; i++) qmod[i] = mpz_fdiv_ui (q, primes[i].p); /* Limit to avoid overflow in i * hmod[j] */ for (i = 0; i < 100000; i++) { unsigned j; for (j = 0; j < nprimes; j++) { if (DIVISIBLE_P(qmod[j] + i * hmod[j], j)) /* q not prime */ goto not_prime; if (DIVISIBLE_P(2*qmod[j] + 1 + 2*i * hmod[j], j)) /* p not prime */ goto not_prime; } fprintf (stderr, "."); mpz_addmul_ui (q, h, i); mpz_mul_2exp (pm1, q, 1); mpz_add_ui (p, pm1, 1); /* Since q is updated, we need to reset i and update qmod */ for (j = 0; j < nprimes; j++) qmod[j] = (qmod[j] + i * hmod[j]) % primes[j].p; i = 0; /* First check if q prime implies p prime. By pocklington, check that gcd (a^2-1, p) = 1 and a^{2q} = 1 (mod p). Need use only a == 2, and then we already know that a^2-1 = 3 doesn't have any common factor with p. */ mpz_set_ui (t, 2); mpz_powm (t, t, q, p); /* If t = +/- 1 (mod p), then t^2 = 1, and the conditions of Pocklingtons's theorem (except q prime, which remain to be checked) are satisfied. On the other hand, if p and q are indeed prime, then 1 or -1 are the only possibilities, since t^2 = a^{p-1} = 1 (mod p), and those values are the only square roots of 1. */ if (mpz_cmp_ui (t, 1) != 0 && mpz_cmp (t, pm1) != 0) goto not_prime; fprintf (stderr, "p"); if (!mpz_millerrabin (q, 25)) goto not_prime; assert (mpz_probab_prime_p (p, 25)); fprintf (stderr, "pq\n"); mpz_swap (r, p); mpz_clears (t, q, p, pm1, h, NULL); free (hmod); free (qmod); return; not_prime: /* Go on with the same i and q */ ; } /* Can this ever happen? */ mpz_addmul_ui (q, h, i); fprintf (stderr, "100000 candidates passed trial division!\n"); } } int main (int argc, char **argv) { mpz_t pi8192, start, step, t, p; int bits; int limit = 1000000; if (argc < 2) { fprintf (stderr,"%s BITS [SIEVE-LIMIT]\n", argv[0]); return EXIT_FAILURE; } bits = atoi(argv[1]); if (bits < 256 || bits > 8192) { fprintf (stderr,"Supported range is 256 <= bits < 8192.\n"); return EXIT_FAILURE; } if (argc > 2) { limit = atoi(argv[2]); if (limit < 4) { fprintf (stderr,"Invalid prime limit.\n"); return EXIT_FAILURE; } } init_table(limit); fprintf (stderr, "Using %u primes for sieving, largest p = %u\n", nprimes, primes[nprimes-1].p); mpz_inits (pi8192, start, step, t, p, NULL); /* floor (pi * 2^8192), computed with pari/gp. This is an 8194 bit number */ mpz_set_str (pi8192, "342668632977872056340614340318593589633845496407221537975716" "613737152546230132865696034849115540419392405119782364448996" "505597009061206839355038690511597649633340755295662641609317" "535642924345851483170828622195425552862989984357380546470618" "654558998494810401062770045070958319118968772694396124916431" "894580767686315880694138861428875902873600542294826287748558" "777680794805812784463450507747144885813404423833320387798321" "609280015466841325521574345612804300925224268961852838014727" "344949392988773343665477596160680355250188118765396205271825" "594335340262310201378513530164474118131690724342410799910757" "546982847641291056024097727491901066776286401345290418249625" "628084349896086834732113313412019501787434146151912994099903" "795562822901556466065108423731653397934665628418225503906500" "252356756723136478156580557983552276992132926102607206902926" "217226186459755888047793134565096032547470753739485581485056" "095310312774412642091527392486496373093667048791992749203017" "039714338536895459352056225848086680604116795009774640833217" "634173864865403767984673414411303165787683355096108212088449" "911140581907950288312790601048394648396324285541310288154248" "299687810226823038493790254875059185044994880417764356982840" "836688145748032677215052979431605921845872542983666091618301" "641191123769382721257794537529591295620218822973870974507625" "710916011007688849347790863162497296922421716445647812915537" "174656134053117238096786067011739714153581530618764175406523" "316433003785370745957635127014688173775323182910793894295533" "869774970638119508426058911918833814428165195037324835873478" "264560759508465057903722354035637978838385867006178927628223" "655893247618439468688098957702197415152483332250099523049205" "947113206854728848346101557957368387613667773778399604898871" "571620512445391665708436224753527427390770571921354058146861" "534703545990059875592521055483476922407124171344793745585445" "612078729092110740281827121644569208704341570355808361384144" "320068653876547846047724572021904389025572441127188782597462" "975206221252835136986819772656964303920606775754918430878535" "831653872047705625068521848678547523189492202180161565293546" "004893947202674258029340791722950503743099899657901284673761" "082932857148614112547296837932346608390996266386438042203034" "975635130970578410146576920597437945752613183601468824949930" "014430184646230304464605951116975119907446615541881480270560" "054980165635722725085125496591712178571547448110006296573138" "030681065709805770745255837670620283490202933751846093959476" "8886090", 10); mpz_setbit (step, 64); mpz_sub_ui (t, step, 1); mpz_mul_2exp (start, t, bits - 64); mpz_add (start, start, t); mpz_fdiv_q_2exp (t, pi8192, (8194 + 128 - bits)); assert (mpz_sizeinbase (t, 2) == bits - 128); mpz_mul_2exp (t, t, 64); mpz_add (start, start, t); next_strong_prime (p, start, step); mpz_sub (t, p, start); mpz_fdiv_q_2exp (t, t, 64); gmp_printf ("p = 0x%Zx\nt = %Zd\n", p, t); mpz_clears (pi8192, start, step, t, p, NULL); free (primes); return EXIT_SUCCESS; } -- Niels Mller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From nobody Wed Mar 12 08:07:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EE71A08ED for ; Wed, 12 Mar 2014 08:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4a8tboZCrCmQ for ; Wed, 12 Mar 2014 08:07:01 -0700 (PDT) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1971C1A08AF for ; Wed, 12 Mar 2014 08:07:00 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id w62so11593363wes.0 for ; Wed, 12 Mar 2014 08:06:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JZpM6nCOHY5RsRsgtthbhioJFkd5xXR8EaMh3zSqJs8=; b=Q6rT9bc4SsPvBkQ/ISHvXFEWv/vm1GO6ezMQIK+acxtCtgokzgk9Gd5pdU36giKTDp m3fW4CwIRIlIjBjJbljoQ5Iwjcqyr3O0FoDNeFcJt1XN87ciYqZn05OdmTlgjSupY5Vh uoQUDCYWqxqOwwZKyp9igQkoSAxk2JxOsYrBYn6o2xNoLT/iWPPs31FOi5JQqJZHyhob 3uKdiGpf0tebSS9B4dfuYhAnU3CkvERkoFACWrPdrf/5Lp+CryozKeiuWK5e//AZYxnn 67prKBK7o42UXKV4gdWhJdmIO17H25BZVBVVHVQAxpX9oAx+NkWUkS2mTg2btBZbm559 cYng== X-Gm-Message-State: ALoCoQmlA7zbJkIrGBvebW5UgKpBYg3e8lA1EsulpMjxWsCbl6YQFns+WLf/2FQVC1yKy7utG9hN MIME-Version: 1.0 X-Received: by 10.194.143.40 with SMTP id sb8mr42315193wjb.15.1394636814571; Wed, 12 Mar 2014 08:06:54 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Wed, 12 Mar 2014 08:06:54 -0700 (PDT) X-Originating-IP: [184.23.29.222] In-Reply-To: <531F9443.1000002@cs.tcd.ie> References: <531F9443.1000002@cs.tcd.ie> Date: Wed, 12 Mar 2014 08:06:54 -0700 Message-ID: From: Trevor Perrin To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e0115e78cec6d7004f46a2fc6 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yGVDOxT_YkzIpRQaEq0dvKXTlg0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS chairing changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 15:07:05 -0000 --089e0115e78cec6d7004f46a2fc6 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 11, 2014 at 3:54 PM, Stephen Farrell wrote: > > Effective April 1st, Sean Turner will become a third TLS > co-chair in order to free up Eric who will be a TLS 1.3 > document editor. Hi Stephen, There was discussion about having a more competitive process for TLS 1.3 [1]. I guess it's been decided to not do that, to use Eric's draft as a base, and appoint Eric as editor? Could you remind me where the WG reached consensus on all this? Trevor [1] http://www.ietf.org/mail-archive/web/tls/current/msg10533.html --089e0115e78cec6d7004f46a2fc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Tue, Mar 11, 2014 at 3:54 PM, Stephen Farrell <stephen.farrell@= cs.tcd.ie> wrote:

Effective April 1st, Sean Turner will become a third TLS
co-chair in order to free up Eric who will be a TLS 1.3
document editor.


Hi Ste= phen,

There was discussion about having a more com= petitive process for TLS 1.3 [1].

I guess it's= been decided to not do that, to use Eric's draft as a base, and appoin= t Eric as editor?

Could you remind me where the WG reached consensus on a= ll this?


Trevor

--089e0115e78cec6d7004f46a2fc6-- From nobody Wed Mar 12 08:43:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA031A0863 for ; Wed, 12 Mar 2014 08:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RspDMYmX5h0h for ; Wed, 12 Mar 2014 08:43:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 59CFF1A074B for ; Wed, 12 Mar 2014 08:43:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8F552BE3F; Wed, 12 Mar 2014 15:43: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 CVQZwKkYL3zD; Wed, 12 Mar 2014 15:43: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 6B5B9BE29; Wed, 12 Mar 2014 15:43:40 +0000 (GMT) Message-ID: <532080AD.6080907@cs.tcd.ie> Date: Wed, 12 Mar 2014 15:43:41 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Trevor Perrin References: <531F9443.1000002@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/93Xlu0TkM11YjK6WDsSU4WoUPbI Cc: "tls@ietf.org" Subject: Re: [TLS] TLS chairing changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 15:43:52 -0000 Hi Trevor, On 03/12/2014 03:06 PM, Trevor Perrin wrote: > On Tue, Mar 11, 2014 at 3:54 PM, Stephen Farrell > wrote: > >> >> Effective April 1st, Sean Turner will become a third TLS >> co-chair in order to free up Eric who will be a TLS 1.3 >> document editor. > > > > Hi Stephen, > > There was discussion about having a more competitive process for TLS 1.3 > [1]. I'm not at all sure a "competition" is the right way to pick an initial draft as a starting point. Of course, people are free to write any I-D they choose and propose that to the WG, but I think that the process being followed so far of discussing the features and building from those seems to be going fine. > I guess it's been decided to not do that, to use Eric's draft as a base, > and appoint Eric as editor? No, however I think that's a reasonably likely occurrence so we're planning for making the process easier and cleaner in the case where it happens. > Could you remind me where the WG reached consensus on all this? Its up to the chairs to decide that, and they will, and part of that would be that Eric moving from chairing creates a good option. And in any case, while the WG consensus will I'm sure be tested at all the right places, you should bear in mind that its entirely up to the WG chairs to hire (and fire) document editors. Lastly, I'd suggest giving Sean a week or so to get back from vacation and chat in detail with Joe and Eric and then I'm sure they'll be proposing how to go forward from there. Cheers, S. > > > Trevor > > > [1] http://www.ietf.org/mail-archive/web/tls/current/msg10533.html > From nobody Wed Mar 12 08:49:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2ECD1A09CA for ; Wed, 12 Mar 2014 08:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 VrS4_eapa09P for ; Wed, 12 Mar 2014 08:49:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F38341A0753 for ; Wed, 12 Mar 2014 08:49:14 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6421340455; Wed, 12 Mar 2014 09:49:08 -0600 (MDT) Message-ID: <532081F3.1080608@stpeter.im> Date: Wed, 12 Mar 2014 09:49:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Farrell , Trevor Perrin References: <531F9443.1000002@cs.tcd.ie> <532080AD.6080907@cs.tcd.ie> In-Reply-To: <532080AD.6080907@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jH-YVU03yxq0ZtI86Pl5LZgpL78 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS chairing changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 15:49:54 -0000 On 3/12/14, 9:43 AM, Stephen Farrell wrote: > > Hi Trevor, > > On 03/12/2014 03:06 PM, Trevor Perrin wrote: >> On Tue, Mar 11, 2014 at 3:54 PM, Stephen Farrell >> wrote: >> >>> >>> Effective April 1st, Sean Turner will become a third TLS >>> co-chair in order to free up Eric who will be a TLS 1.3 >>> document editor. >> >> >> >> Hi Stephen, >> >> There was discussion about having a more competitive process for TLS 1.3 >> [1]. > > I'm not at all sure a "competition" is the right way to pick > an initial draft as a starting point. Of course, people are > free to write any I-D they choose and propose that to the WG, > but I think that the process being followed so far of discussing > the features and building from those seems to be going fine. IMHO, basically starting from RFC 5246 will improve transparency. Speaking of which, let me send the XML-ized version I have to Eric. Peter From nobody Wed Mar 12 09:22:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B8D1A09DA for ; Wed, 12 Mar 2014 09:22:10 -0700 (PDT) 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_44=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 Wa6KTZzRFd6k for ; Wed, 12 Mar 2014 09:22:05 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DA46C1A09D7 for ; Wed, 12 Mar 2014 09:21:43 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id i11so10402834oag.34 for ; Wed, 12 Mar 2014 09:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FTca3psAw5mTG88azVwgh3UyttpUrpIizwQ+2hzoYyc=; b=OpZGc4Zsz1SRoae7kxEyF6AHT2/4kX3rjHU1Oyr64YqlDMvx5NMmKmmXGIpwV4xgMN iyQYz0ZimofXIfKBNiGEcZvdbPApryXpM4oR4Dn3kZ6Ou26KN5T8uQycW6QTSMH0t79p CHXo1SAgzeof85OdtyUIxSfOl8D7AOJVWqoX49YLFTfcsBavhoxn9adv6wquTckfaknk 4JKyeduFuzHxbRMX4UwXJej2PhPnWbEZVlyQtR4Ojg5e7uyW1iD4m4LrfPKQjGpyu6ru NwvHc5gJjI1aUg6GemnLbVqYHlg9H7iXE/52tjRsIysFdkibe+8rE01NQCuh43O2h2ge 1Jxg== MIME-Version: 1.0 X-Received: by 10.182.142.5 with SMTP id rs5mr39245800obb.39.1394641297626; Wed, 12 Mar 2014 09:21:37 -0700 (PDT) Received: by 10.76.91.169 with HTTP; Wed, 12 Mar 2014 09:21:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Mar 2014 21:51:37 +0530 Message-ID: From: Sajeev S To: ekr@rtfm.com Content-Type: multipart/alternative; boundary=001a11c2d3b622e7c304f46b3b9b Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AUB5JS42yJVnQDQ_q7wtOxqWiX8 Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 Wish List Suggestions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 16:22:10 -0000 --001a11c2d3b622e7c304f46b3b9b Content-Type: text/plain; charset=ISO-8859-1 Hi Eric, Just a thought----------for this section https://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00 5.4 . Some other questions to think about [TODO] o Should we get rid of resumption? Can we have the port no which can be used for Resumption in the initial Handshake flow. This data(port no) can be a encrypted message. Regards, Sajeev On Sat, Nov 23, 2013 at 10:58 PM, Sajeev S wrote: > Hi Eric, > > My self Sajeev, I have over 7+ years of expertise in Testing SSL/TLS > protocol and PKI. > > I read through the " > https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf" > > I have one suggestion for this "TLS 1.3 Wish List" > > Can we add an TLS Extension field when we use TLS 1.3 as protocol version, > which will inform the Certificate key size bits to be used in the SSL/TLS > transaction. > > As we move forward in the SSL/TLS security,the certificate key size bits > will play an important role. > > Proposal-----------> > 1. Client hello will have extension saying that we will use 1024/2048/4096 > public key bit size certificates > 2. Server hello will send an extension which will decide which key size to > be used. > > The above key size bit extension can be used for deciding both Server > certificates and client certificates. > > It is just an idea........need to analyse more because not only RSA/DSA > certificates will be used. > It also depends on which ciphersuite gets select..........if it is ECC > based or DH based. > > we can also have the size for DH key. > > For EC based we already have curve and point extensions. > > Please let me know if it is feasible to add this functionality? > > Regards, > Sajeev > > > > --001a11c2d3b622e7c304f46b3b9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Eric,

Just a thought----------for th= is section


5.4.  Some other questions to think about


   [TODO]

   o  Should we get rid of resumption?

Can w= e have the port no which can be used for Resumption in the initial Handshak= e flow.

This data(port no) can be a encrypted mess= age.

Regards,
Sajeev


=




On Sat, Nov 23, 2013 at 10:58 PM, Sajeev S <saju= always@gmail.com> wrote:
Hi=A0Eric,

My self Saj= eev, I have =A0over 7+ years of expertise in Testing SSL/TLS protocol and P= KI.


I have one suggestion for this "TLS 1.3 Wish List&= quot;

Can we add an TLS Extension field when we us= e TLS 1.3 as protocol version, which will inform the Certificate key size b= its to be used in the SSL/TLS transaction.

As we move forward in the SSL/TLS security,the ce= rtificate key size bits will play an important role.

Proposal----------->
1. Client hello will have extension sa= ying that we will use 1024/2048/4096 public key bit size certificates =A0= =A0
2. Server hello will send an extension which will decide which k= ey size to be used.

The above key size bit extensi= on can be used for deciding both Server certificates and client certificate= s.

=A0It is just an idea........need to analyse more becau= se not only RSA/DSA certificates will be used.
It also depends on= which ciphersuite gets select..........if it is ECC based or DH based.

we can also have the size for DH key.=A0

=
For EC based we already have curve and point extensions.

Please let me know if it is feasible to add this function= ality?

Regards,
Sajeev


=


--001a11c2d3b622e7c304f46b3b9b-- From nobody Wed Mar 12 09:26:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB061A09B3 for ; Wed, 12 Mar 2014 09:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScfUF_8U0RyY for ; Wed, 12 Mar 2014 09:26:49 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by ietfa.amsl.com (Postfix) with ESMTP id C12A91A0759 for ; Wed, 12 Mar 2014 09:26:48 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id n12so11827938wgh.24 for ; Wed, 12 Mar 2014 09:26:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HJQ0vrXkK/wlRjIMrp2ChSnnmp96Etp2F71ueundBHI=; b=U1kJ1hg3jwnBTP3s64MMz45oNEc21EJzceDygXfssPsj8EFG9Hc7eFfgc5I8CI6x9y eP/vD36AXJjya/0YKjfPhv1IARhz3xG+Ix4T4KHTQ6bYpP7pso4u0LXMRiB2zMxzkEPn uVxUV7ilh8AO9UPTBVGB8IAnSpYuiOoAr0A2REa38QV4wZv3ldimmizxfdHE4P6AtjF9 bWErDVvEdKauO0hbZI5rOtbEcpnpDxXXPguS3eMFLSSNLJohr7rT5ynZGoJlJErotA3g z/tEQMCbmtbOMPTmc0VZ5LDAVD/ibjrRgjOj9r0xCEg7B5a1ROAAmhkpDWbanvlsoxN9 gMug== X-Gm-Message-State: ALoCoQlnSwWgTEoRKucfDljDRoqanJAtPPOwJ56jxGPW6q/VZqbn/DP9fIP0rIW4dUSsDO29XBz+ X-Received: by 10.194.92.38 with SMTP id cj6mr1997220wjb.70.1394641602225; Wed, 12 Mar 2014 09:26:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 12 Mar 2014 09:26:01 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Wed, 12 Mar 2014 09:26:01 -0700 Message-ID: To: Sajeev S Content-Type: multipart/alternative; boundary=047d7bfd07964a3a6704f46b4d93 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Xnu8_D0l9EHYLujaDRK09nHpxl4 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Wish List Suggestions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 16:26:53 -0000 --047d7bfd07964a3a6704f46b4d93 Content-Type: text/plain; charset=ISO-8859-1 Sajeev, Can you expand on this topic a bit? Are you talking about the UDP/TCP port #? Something else? -Ekr On Wed, Mar 12, 2014 at 9:21 AM, Sajeev S wrote: > Hi Eric, > > Just a thought----------for this section > https://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00 > > 5.4 . Some other questions to think about > > [TODO] > > o Should we get rid of resumption? > > > Can we have the port no which can be used for Resumption in the initial > Handshake flow. > > This data(port no) can be a encrypted message. > > Regards, > Sajeev > > > > > > > On Sat, Nov 23, 2013 at 10:58 PM, Sajeev S wrote: > >> Hi Eric, >> >> My self Sajeev, I have over 7+ years of expertise in Testing SSL/TLS >> protocol and PKI. >> >> I read through the " >> https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf" >> >> I have one suggestion for this "TLS 1.3 Wish List" >> >> Can we add an TLS Extension field when we use TLS 1.3 as protocol >> version, which will inform the Certificate key size bits to be used in the >> SSL/TLS transaction. >> >> As we move forward in the SSL/TLS security,the certificate key size bits >> will play an important role. >> >> Proposal-----------> >> 1. Client hello will have extension saying that we will use >> 1024/2048/4096 public key bit size certificates >> 2. Server hello will send an extension which will decide which key size >> to be used. >> >> The above key size bit extension can be used for deciding both Server >> certificates and client certificates. >> >> It is just an idea........need to analyse more because not only RSA/DSA >> certificates will be used. >> It also depends on which ciphersuite gets select..........if it is ECC >> based or DH based. >> >> we can also have the size for DH key. >> >> For EC based we already have curve and point extensions. >> >> Please let me know if it is feasible to add this functionality? >> >> Regards, >> Sajeev >> >> >> >> > --047d7bfd07964a3a6704f46b4d93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sajeev,

Can you expand on this topic a = bit? Are you talking about the
UDP/TCP port #? Something else?

-Ekr


On Wed, Mar 12, 2014 at 9:21 AM, Sajeev S <s= ajualways@gmail.com> wrote:
Hi Eric,

Just a thought----------for th= is section


5.4.  Some other questions to think about


   [TODO]

   o  Should we get rid of resumption?

Can w= e have the port no which can be used for Resumption in the initial Handshak= e flow.

This data(port no) can be a encrypted mess= age.

Regards,
Sajeev
<= div>





On Sat, Nov 23, 2013 at 10:58= PM, Sajeev S <sajualways@gmail.com> wrote:
Hi=A0Eric,

My self Saj= eev, I have =A0over 7+ years of expertise in Testing SSL/TLS protocol and P= KI.


I have one suggestion for this "TLS 1.3 Wish List&= quot;

Can we add an TLS Extension field when we us= e TLS 1.3 as protocol version, which will inform the Certificate key size b= its to be used in the SSL/TLS transaction.

As we move forward in the SSL/TLS security,the ce= rtificate key size bits will play an important role.

Proposal----------->
1. Client hello will have extension sa= ying that we will use 1024/2048/4096 public key bit size certificates =A0= =A0
2. Server hello will send an extension which will decide which k= ey size to be used.

The above key size bit extensi= on can be used for deciding both Server certificates and client certificate= s.

=A0It is just an idea........need to analyse more becau= se not only RSA/DSA certificates will be used.
It also depends on= which ciphersuite gets select..........if it is ECC based or DH based.

we can also have the size for DH key.=A0

=
For EC based we already have curve and point extensions.

Please let me know if it is feasible to add this function= ality?

Regards,
Sajeev


=



--047d7bfd07964a3a6704f46b4d93-- From nobody Wed Mar 12 10:20:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E7A1A04A7 for ; Wed, 12 Mar 2014 10:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bqsbqna-lyHz for ; Wed, 12 Mar 2014 10:20:17 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) by ietfa.amsl.com (Postfix) with ESMTP id A0B341A074A for ; Wed, 12 Mar 2014 10:20:16 -0700 (PDT) Received: from [192.168.202.157] (pool-108-39-221-65.pitbpa.fios.verizon.net [108.39.221.65]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s2CHJuMw017129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 12 Mar 2014 13:19:59 -0400 (EDT) Message-ID: <1394644793.23530.30.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Peter Gutmann Date: Wed, 12 Mar 2014 13:19:53 -0400 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C737238A20F@uxcn10-6.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C737238A20F@uxcn10-6.UoA.auckland.ac.nz> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.201 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PnAOrgHikjTqSO9nKmdLh38vy2c Cc: "ietf-ssh@netbsd.org" , "" , jhutz@cmu.edu Subject: Re: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 17:20:27 -0000 On Wed, 2014-03-12 at 00:25 +0000, Peter Gutmann wrote: > This is from an early Oakley draft draft-ietf-ipsec-isakmp-oakley-03.txt that > references another Oakley draft draft-ietf-ipsec-oakley-01.txt which, however, > doesn't actually contain the text quoted above. So I guess the reference > would be [Citation needed ^ 2] or [Apocryphal ^ 2]. Actually, that text _does_ appear in RFC2412, in the introduction to appendix E, where the first five well-known groups are defined. The groups defined in RFC3526 have the same structure, but while that document does make reference to RFC2412, it does not actually claim the same method was used to select them. This should be relatively easy to verify, however. The MODP groups given in RFC5114 are taken from DSS and NIST SP-800-56A, and do not have this same structure. The RFC has nothing to say on how they were selected, and my recollection from the last time I looked was that the NIST publications don't say anything either. -- Jeff From nobody Wed Mar 12 10:34:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927411A0745 for ; Wed, 12 Mar 2014 10:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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_42=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XN0sZQlFe3SG for ; Wed, 12 Mar 2014 10:34:50 -0700 (PDT) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD401A0552 for ; Wed, 12 Mar 2014 10:34:50 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id uz6so10358390obc.29 for ; Wed, 12 Mar 2014 10:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2b3NFGzpVtO9Dl8cVLYzhpG0KQtGVD9tQFEBtVgpxTA=; b=ndzSV11suLb5zh/APtoRD3rco0jCaqpKyX57OXDclggW2wlelX400/7uzH2t06+LnU iC39X0l9dJMASNzSVN55jozuLFPtPYEsVn0WUcv3ThNAwdaCOf9EhDPY1oQYYhgeCryI cmxmMAWs9sxTIegMNgplVIZobSKPspe2BMiMN0494nulcJy68GWAt1VFsPqqSQ/arUD/ +CBMtToAsczOgjCoZPt5fbr+MBAwPRd3wiEkID78swyteLuGDk1qHnOWCOrVQa8fJoIo pc4h6ZT1QVUR6ftkm/xxYp8UylpGDDlKpgjGaZkPK225RmQQnDJN/bk+uJHm4mAvDWb+ cTlg== MIME-Version: 1.0 X-Received: by 10.182.117.195 with SMTP id kg3mr38907449obb.17.1394645648980; Wed, 12 Mar 2014 10:34:08 -0700 (PDT) Received: by 10.76.91.169 with HTTP; Wed, 12 Mar 2014 10:34:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Mar 2014 23:04:08 +0530 Message-ID: From: Sajeev S To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e0149c5067ec11704f46c3efb Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zX-cw5sw4tEcjKXaA8Mv6G6vbWY Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Wish List Suggestions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 17:34:54 -0000 --089e0149c5067ec11704f46c3efb Content-Type: text/plain; charset=ISO-8859-1 The port TCP(TLS) / UDP(DTLS) for which the server listens for Resumption. This will make the client to send the Reuse request for this particular server on this pre-negotiated port(to be included in the initial Handshake flow) This will also make Reuse request binded with initial Handshake. The port number to be used can be a new encrypted handshake message sent after Finished Handshake message or During application data transfer and Before sending close notify message Server should listen on the same tcp/udp port to do a reuse request. Just a thought................... Regards, Sajeev On Wed, Mar 12, 2014 at 9:56 PM, Eric Rescorla wrote: > Sajeev, > > Can you expand on this topic a bit? Are you talking about the > UDP/TCP port #? Something else? > > -Ekr > > > > On Wed, Mar 12, 2014 at 9:21 AM, Sajeev S wrote: > >> Hi Eric, >> >> Just a thought----------for this section >> https://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00 >> >> 5.4 . Some other questions to think about >> >> [TODO] >> >> o Should we get rid of resumption? >> >> >> Can we have the port no which can be used for Resumption in the initial >> Handshake flow. >> >> This data(port no) can be a encrypted message. >> >> Regards, >> Sajeev >> >> >> >> >> >> >> On Sat, Nov 23, 2013 at 10:58 PM, Sajeev S wrote: >> >>> Hi Eric, >>> >>> My self Sajeev, I have over 7+ years of expertise in Testing SSL/TLS >>> protocol and PKI. >>> >>> I read through the " >>> https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf" >>> >>> I have one suggestion for this "TLS 1.3 Wish List" >>> >>> Can we add an TLS Extension field when we use TLS 1.3 as protocol >>> version, which will inform the Certificate key size bits to be used in the >>> SSL/TLS transaction. >>> >>> As we move forward in the SSL/TLS security,the certificate key size bits >>> will play an important role. >>> >>> Proposal-----------> >>> 1. Client hello will have extension saying that we will use >>> 1024/2048/4096 public key bit size certificates >>> 2. Server hello will send an extension which will decide which key size >>> to be used. >>> >>> The above key size bit extension can be used for deciding both Server >>> certificates and client certificates. >>> >>> It is just an idea........need to analyse more because not only RSA/DSA >>> certificates will be used. >>> It also depends on which ciphersuite gets select..........if it is ECC >>> based or DH based. >>> >>> we can also have the size for DH key. >>> >>> For EC based we already have curve and point extensions. >>> >>> Please let me know if it is feasible to add this functionality? >>> >>> Regards, >>> Sajeev >>> >>> >>> >>> >> > --089e0149c5067ec11704f46c3efb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The port TCP(TLS) / UDP(DTLS) for whic= h the server listens for Resumption.

This will mak= e the client to send the Reuse request for this particular server on this p= re-negotiated port(to be included in the initial Handshake flow)

This will also make Reuse request binded with initial H= andshake.

The port number to be used can be a new = encrypted handshake message sent after=A0
Finished Handshake mess= age=A0
or=A0
During application data transfer=A0
and=A0
Before sending close notify message

S= erver should listen on the same tcp/udp port to do a reuse request.=A0

Just a thought...................

R= egards,
Sajeev




On Wed, Mar 12, 2014 at= 9:56 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Sajeev,

= Can you expand on this topic a bit? Are you talking about the
UDP= /TCP port #? Something else?

-Ekr



On Wed, Mar 12, 2014 at 9:21 AM, Sajeev S <s= ajualways@gmail.com> wrote:
Hi Eric,

Just a thought----------for th= is section


5.4.  Some other questions to t=
hink about



   [TODO]

   o  Should we get rid of resumption?

Can w= e have the port no which can be used for Resumption in the initial Handshak= e flow.

This data(port no) can be a encrypted mess= age.

Regards,
Sajeev





On Sat, Nov 23, 2013 at 10:58 PM, Sajeev S= <sajualways@gmail.com> wrote:
Hi=A0Eric,

My self Saj= eev, I have =A0over 7+ years of expertise in Testing SSL/TLS protocol and P= KI.


I have one suggestion for this "TLS 1.3 Wish List&= quot;

Can we add an TLS Extension field when we us= e TLS 1.3 as protocol version, which will inform the Certificate key size b= its to be used in the SSL/TLS transaction.

As we move forward in the SSL/TLS security,the ce= rtificate key size bits will play an important role.

Proposal----------->
1. Client hello will have extension sa= ying that we will use 1024/2048/4096 public key bit size certificates =A0= =A0
2. Server hello will send an extension which will decide which k= ey size to be used.

The above key size bit extensi= on can be used for deciding both Server certificates and client certificate= s.

=A0It is just an idea........need to analyse more becau= se not only RSA/DSA certificates will be used.
It also depends on= which ciphersuite gets select..........if it is ECC based or DH based.

we can also have the size for DH key.=A0

=
For EC based we already have curve and point extensions.

Please let me know if it is feasible to add this function= ality?

Regards,
Sajeev


=




--089e0149c5067ec11704f46c3efb-- From nobody Wed Mar 12 10:39:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DA31A0552 for ; Wed, 12 Mar 2014 10:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AomaHR5gBnvs for ; Wed, 12 Mar 2014 10:39:07 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1CD1A048A for ; Wed, 12 Mar 2014 10:39:07 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 647BBF984; Wed, 12 Mar 2014 13:38:59 -0400 (EDT) Message-ID: <53209BB3.4000001@fifthhorseman.net> Date: Wed, 12 Mar 2014 13:38:59 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: Jeffrey Hutzelman , Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C737238A20F@uxcn10-6.UoA.auckland.ac.nz> <1394644793.23530.30.camel@destiny.pc.cs.cmu.edu> In-Reply-To: <1394644793.23530.30.camel@destiny.pc.cs.cmu.edu> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tB43xxXnDwSsgsx4nGsPs65ujrApHuOAk" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JSncagYW_FzdnJQ2NyGQlqRQjrI Cc: "ietf-ssh@netbsd.org" , "" Subject: Re: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 17:39:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tB43xxXnDwSsgsx4nGsPs65ujrApHuOAk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/12/2014 01:19 PM, Jeffrey Hutzelman wrote: > The MODP groups given in RFC5114 are taken from DSS and NIST SP-800-56A= , > and do not have this same structure. The RFC has nothing to say on how= > they were selected, and my recollection from the last time I looked was= > that the NIST publications don't say anything either. It's not clear to me that there is any advantage in a DH key exchange to using the RFC 5114 discrete log groups. The selection of a discrete log group with a subgroup of targeted size q (instead of using a group with a safe prime modulus, which only allows subgroups of at worst (p-1)/2 if you exclude (p-1) as a valid public key) makes it costly to check whether the peer is forcing your shared secret into one of the other smaller subgroups. Note that this kind of subgroup-forcing attack was used in the DHE variant of Bhargavan et al's recent attack against client certification in TLS (other mistakes in the TLS protocol played a role in these attacks too, of course) Using a group with a known safe prime modulus should avoid this concern. --dkg --tB43xxXnDwSsgsx4nGsPs65ujrApHuOAk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTIJuzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcjOcQALChFpJeivX2wF4odGMw5M9k DLIeDft4hUEa12tjGF0N0cWXtTk9cuhG9uwAQS1wmJJmMTpaELlX2kBan9L77tos 8YEKi/G7ZqU/0VwW5tGE6kV3J602Xojb5z1ZJFz+q4+PksG1PZDD6unCklHpmxQo XOW67JjekFFKNpL2W8WUHAHIAyBW/XVZaSN+MLc4S2h/SZNW8HCIuOA+GXO+hsdT OX4itYHvK9piWNwm2No41cgSnO47WfRiSms3gHcqDQ1I1jUEdwp41VvbH0+xD5u7 nbgwKKWed9NgRjdAE3jn6+uDDTOvKNIPR7/FNvlZW59cIMV//kSAfQpEfbgccKhB lp8EL8KAvh1yBWqQ++hJ7ORjGr31hn7My+d8utAp+G5WPPu78T3Q9V8ybnFS8hIb Nz4joyBcnbYHdJyWTpzJ0f0cMjiWHno7ob6p52OXLA+6eKVWGxK+OoivhDtmX+uI IQ39oR7GmRSBo3or0BBwdXJYxKyLKtw9Jgti4goBjZ/fSMVU8M/Eh8CkK0h7EiLN xl+SVfNvkRkqWyfEP95iFbvfGgUWm+KESBWClIM5U/7vFCwcDOcjEar8FX/Qg27K ryRJg+OQC/h89PCWeBzPbnXbj9od+Jy5wZcBOmlJ3f+FJnDNm7eK2CLGBZJt5YUr dd8aX2wcgK/dpu3sOnNJ =BW9w -----END PGP SIGNATURE----- --tB43xxXnDwSsgsx4nGsPs65ujrApHuOAk-- From nobody Wed Mar 12 11:19:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8D11A0736 for ; Wed, 12 Mar 2014 11:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 VGxRwH9J9qw4 for ; Wed, 12 Mar 2014 11:19:13 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 49AC31A0493 for ; Wed, 12 Mar 2014 11:19:13 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id x13so11887384wgg.14 for ; Wed, 12 Mar 2014 11:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+VqtJDt9eZb6GitLSp2KriouRZutYQpu7qe8HcQ6OmU=; b=HMMANlOk5r9ikbNstFWhK7kozB6wHt47zm6Zl56V113K0HTFP/KPGR8VNi/jVs4xN8 rXUxUyyItkyaHfm/26JiMONIeTd86KSAuOshqRYO0FwexYCpyoiqjND5pKCGXG0PYc7x 9jQcTCRs6iZflKZ1ZnpuUcwsxb+zaLjoC5pVlHQRtDuHl02G1wi/pKX6aAPQ4Ac7jgCo qIbAwhNuK/OfYdUXjdbjlN3k9jK1SqiNmK3EGyPIQVcJy4zY/ettlFbNBC2uI69bsZOX KFCxFCe+anFOyQlc6IuOdubeIGdZhk+ii6iWb/Ao53WbTHYUu7pf/9AcLuGDiiOzDV2n mE4g== MIME-Version: 1.0 X-Received: by 10.181.12.16 with SMTP id em16mr8985236wid.3.1394648346695; Wed, 12 Mar 2014 11:19:06 -0700 (PDT) Received: by 10.194.158.105 with HTTP; Wed, 12 Mar 2014 11:19:06 -0700 (PDT) Received: by 10.194.158.105 with HTTP; Wed, 12 Mar 2014 11:19:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Mar 2014 14:19:06 -0400 Message-ID: From: Quynh Dang To: Sajeev S , tls@ietf.org Content-Type: multipart/alternative; boundary=f46d0434c0a04a9efc04f46cdfc7 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/l2_3Wbff0FGY0iuxiYP7Fg3xQYQ Subject: Re: [TLS] TLS 1.3 Wish List Suggestions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 18:19:15 -0000 --f46d0434c0a04a9efc04f46cdfc7 Content-Type: text/plain; charset=ISO-8859-1 Dear all, I urged for these two features before. I think they would be good for security reason. Regards, Quynh. On Nov 23, 2013 3:16 PM, "Sajeev S" wrote: > Hi Eric, > > My self Sajeev, I have over 7+ years of expertise in Testing SSL/TLS > protocol and PKI. > > I read through the " > https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf" > > I have one suggestion for this "TLS 1.3 Wish List" > > Can we add an TLS Extension field when we use TLS 1.3 as protocol version, > which will inform the Certificate key size bits to be used in the SSL/TLS > transaction. > > As we move forward in the SSL/TLS security,the certificate key size bits > will play an important role. > > Proposal-----------> > 1. Client hello will have extension saying that we will use 1024/2048/4096 > public key bit size certificates > 2. Server hello will send an extension which will decide which key size to > be used. > > The above key size bit extension can be used for deciding both Server > certificates and client certificates. > > It is just an idea........need to analyse more because not only RSA/DSA > certificates will be used. > It also depends on which ciphersuite gets select..........if it is ECC > based or DH based. > > we can also have the size for DH key. > > For EC based we already have curve and point extensions. > > Please let me know if it is feasible to add this functionality? > > Regards, > Sajeev > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --f46d0434c0a04a9efc04f46cdfc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dear all, I urged for these two features before. I think the= y would be good for security reason. Regards, Quynh.

On Nov 23, 2013 3:16 PM, "Sajeev S" &l= t;sajualways@gmail.com> wrot= e:
Hi=A0Eric,

My self Sajeev, I have =A0ov= er 7+ years of expertise in Testing SSL/TLS protocol and PKI.

I have one suggestion for this "TLS 1.3 Wish List&= quot;

Can we add an TLS Extension field when we us= e TLS 1.3 as protocol version, which will inform the Certificate key size b= its to be used in the SSL/TLS transaction.

As we move forward in the SSL/TLS security,the ce= rtificate key size bits will play an important role.

Proposal----------->
1. Client hello will have extension sa= ying that we will use 1024/2048/4096 public key bit size certificates =A0= =A0
2. Server hello will send an extension which will decide which k= ey size to be used.

The above key size bit extensi= on can be used for deciding both Server certificates and client certificate= s.

=A0It is just an idea........need to analyse more becau= se not only RSA/DSA certificates will be used.
It also depends on= which ciphersuite gets select..........if it is ECC based or DH based.

we can also have the size for DH key.=A0

=
For EC based we already have curve and point extensions.

Please let me know if it is feasible to add this function= ality?

Regards,
Sajeev


=


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

--f46d0434c0a04a9efc04f46cdfc7-- From nobody Wed Mar 12 12:09:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E2D1A0365 for ; Wed, 12 Mar 2014 12:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 akvy9ZOP8SQ8 for ; Wed, 12 Mar 2014 12:09:17 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (agjbgdcfdbea.dreamhost.com [69.163.253.140]) by ietfa.amsl.com (Postfix) with ESMTP id 356641A0772 for ; Wed, 12 Mar 2014 12:09:17 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 33F832005D10D for ; Wed, 12 Mar 2014 12:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Z7Nt0tdih1vvmtx8ZqHm PI6eb9k=; b=qajnqvzqX+lWsNbO3fpxFpYTfA7THJ3MEyGfjIye4wCjPkyW6GWP rGNH5vGNJOWSQvJ7Ekmho+mKnFIATfoHUJg437Kr+6YKTZduDvVqFQlLlPmztJLQ x6OtmxDcEo4126auRZ+UZsdH2yWmOOU4HWBSA+YeLpJT6F+uQ6lGCGI= Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id DBE222005D10C for ; Wed, 12 Mar 2014 12:09:10 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so9499641wgh.27 for ; Wed, 12 Mar 2014 12:09:09 -0700 (PDT) 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=RTUDmgtA4n0vbT4oxwFvM+lTnrBvnOZGRNRFd4Z3ArU=; b=IZg7LVh8gDFTq5/4nS5K9sVLqCNIsT3BBbyYnK104pdQCRH5tfQWTYjEl+nogErLuf 5jLi0+6MwxLVEaeN9+/5IEOO9IqbsylKrSbb0qnNgTzSj18qM7SBeBpELxlXEYpyhqHt rMRCDAtwf1BSqGs+QBTxDioiEolInyoyO1x8+JGGfqRRqD8c0lspw3DT+J1rUha0W10Y puO0Va3n835AxhtCJT4J/Vq2pukCTSJsjYMbmjEklsAiXxhG+LS49bqgGhnpOWoOUxHZ DQ9FZsuAcXnFpBz5QGQpmAij/HAL/YKmVyWWD1B0bhUrNXNIJPQdmwSAnfadZ2sA+Cv1 eNQw== MIME-Version: 1.0 X-Received: by 10.194.57.239 with SMTP id l15mr20117767wjq.40.1394651349571; Wed, 12 Mar 2014 12:09:09 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 12:09:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Mar 2014 14:09:09 -0500 Message-ID: From: Nico Williams To: Sajeev S Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dhjgSgKuJvFrUSYy1ShJ-Z-p7uE Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Wish List Suggestions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 19:09:19 -0000 On Wed, Mar 12, 2014 at 11:21 AM, Sajeev S wrote: > Just a thought----------for this section > https://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00 > > > 5.4. Some other questions to think about > > [TODO] > > o Should we get rid of resumption? Why? But we should get rid of resumption without resumption tickets. Resumption session caches on the server side are very hard to get right. Nico -- From nobody Wed Mar 12 12:23:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35291A0754 for ; Wed, 12 Mar 2014 12:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.1 X-Spam-Level: *** X-Spam-Status: No, score=3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347, RDNS_NONE=0.793] 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 3bOOsd-Uf-Kl for ; Wed, 12 Mar 2014 12:23:00 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (unknown [69.163.253.163]) by ietfa.amsl.com (Postfix) with ESMTP id EAFFB1A074E for ; Wed, 12 Mar 2014 12:22:59 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id E7EAB594075 for ; Wed, 12 Mar 2014 12:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=1v0XoeUASQFH2bEgUilT 5RPzhLw=; b=pkp8/OZASiiosR4X1QCllAjftrLPhvZ8PMGrhfOLSWcRtuJnFzO1 bvSx0KSOwPQKnsVstm+BJ9y3mwuPP/cY1SQ0krm10esaqxHpdQQObbk5JSUBTmtR QTx2/ADjXFxqg2bIknahqpfCGKP9nZRIjRl5IXRsiPRqIVQUXuPgZdc= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 95622594072 for ; Wed, 12 Mar 2014 12:22:53 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so12033258wgg.9 for ; Wed, 12 Mar 2014 12:22:52 -0700 (PDT) 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=Bd+ZU3cVH4jbVPV20vwhWNjbIRDAKrEg+6LuIE8psws=; b=ipo/jnkO4pT78eD8pVsKmUt3jTqopA48AI+I+ricREbuMhXePtVh798GI7BTVjhBcf jG+kl7uTFajikZlKsBNCM/TSxOeTm9cC2JApL47ubXI/sRRcFFGecpMbeYCuKopUeNZO 5UszNhEorz0OkJasV7lBUMM+LrBxtd1O1g4fc2VmGF54t9Rr3az2mRUZQm0no32L2wmx qtbidjCa0skIgh1TIwD7iOIqFxMdh/Nr3mhPOa9haDJUtevxFoYxUvjZF6EgRqGaDeNf 0Fo2YB/hoqBmjkbQbomgSEhWFpgyrP2fL4HQkRd/JaVrDE+HyXrRR9p/lzT6M0BvbeAv haXQ== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr9055879wib.5.1394652172373; Wed, 12 Mar 2014 12:22:52 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 12:22:52 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Mar 2014 14:22:52 -0500 Message-ID: From: Nico Williams To: Sajeev S Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tFxIn4UXwQglux1fccYz4kDTVWc Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Wish List Suggestions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 19:23:00 -0000 On Wed, Mar 12, 2014 at 12:34 PM, Sajeev S wrote: > The port TCP(TLS) / UDP(DTLS) for which the server listens for Resumption. There's no such thing as a "TLS port", therefore there can't really be such a thing as a "port for TLS resumption". And it'd be a terrible idea to say that TLS resumption for {HTTP, IMAP, SMTP, SUBMIT, LDAP, ...} must happen on a different port. Nico -- From nobody Wed Mar 12 12:25:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8BA1A0644 for ; Wed, 12 Mar 2014 12:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 cE7YImXNSiWM for ; Wed, 12 Mar 2014 12:25:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5607C1A0768 for ; Wed, 12 Mar 2014 12:25:45 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1F46140455; Wed, 12 Mar 2014 13:25:38 -0600 (MDT) Message-ID: <5320B4B2.70801@stpeter.im> Date: Wed, 12 Mar 2014 13:25:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1mmMAXUArDIATLRs2GA88T_LbzU Subject: Re: [TLS] TLS 1.3 Wish List Suggestions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 19:25:48 -0000 On 3/12/14, 1:09 PM, Nico Williams wrote: > On Wed, Mar 12, 2014 at 11:21 AM, Sajeev S wrote: >> Just a thought----------for this section >> https://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00 >> >> >> 5.4. Some other questions to think about >> >> [TODO] >> >> o Should we get rid of resumption? > > Why? But we should get rid of resumption without resumption tickets. For all TLS-using application protocols, or mainly for HTTP? > Resumption session caches on the server side are very hard to get > right. All of this is hard to get right. :-) Peter From nobody Wed Mar 12 12:29:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295F61A0788 for ; Wed, 12 Mar 2014 12:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aPEqwfsTWLB for ; Wed, 12 Mar 2014 12:29:31 -0700 (PDT) Received: from bacon.lysator.liu.se (vindbrygga.lysator.liu.se [IPv6:2001:6b0:17:f0a0::de]) by ietfa.amsl.com (Postfix) with ESMTP id BC2F01A0786 for ; Wed, 12 Mar 2014 12:29:28 -0700 (PDT) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s2CJTJsm009018; Wed, 12 Mar 2014 20:29:19 +0100 (MET) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s2CJTItS009017; Wed, 12 Mar 2014 20:29:18 +0100 (MET) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: henrick@streamsec.se References: <9A043F3CF02CD34C8E74AC1594475C7372387C9E@uxcn10-6.UoA.auckland.ac.nz> <201403072318.SAA28740@Chip.Rodents-Montreal.ORG> <20140308102142.GA25856@roeckx.be> <42833.1394302378@eng-mail01.juniper.net> <531F8ADF.3060002@fifthhorseman.net> <531FB5DC.1010001@streamsec.se> <53202E8D.9090403@streamsec.se> Date: Wed, 12 Mar 2014 20:29:18 +0100 In-Reply-To: ("Niels =?iso-8859-1?Q?M=F6ller=22's?= message of "Wed, 12 Mar 2014 15:08:05 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fjqfsOZfVyRUfW9cS7zXGJOw-XE Cc: ietf-ssh@netbsd.org, IETF TLS WG Subject: Re: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 19:29:33 -0000 nisse@lysator.liu.se (Niels Mller) writes: > 1. This is a quick hack, not thoroughly tested or profiled, etc. And memory allocation was totally broken. I've put an updated version at http://www.lysator.liu.se/~nisse/misc/next-strong-prime.c Regards, /Niels -- Niels Mller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From nobody Wed Mar 12 12:33:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0441A0479 for ; Wed, 12 Mar 2014 12:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.357 X-Spam-Level: * X-Spam-Status: No, score=1.357 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 jKk_V-enoq-v for ; Wed, 12 Mar 2014 12:33:01 -0700 (PDT) Received: from smtp-01-out.s.azet.sk (smtp-09-out.s.azet.sk [91.235.53.34]) by ietfa.amsl.com (Postfix) with ESMTP id 02A861A0473 for ; Wed, 12 Mar 2014 12:33:00 -0700 (PDT) X-Virus-Scanned: by AntiSpam at azet.sk Received: from [0.0.0.0] (afo7.torproject.afo-tm.org [85.114.142.172]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id 9311486 for ; Wed, 12 Mar 2014 20:32:49 +0100 (CET) X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk 9311486 Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk Message-ID: <5320B65E.9070804@azet.sk> Date: Wed, 12 Mar 2014 20:32:46 +0100 From: Fedor Brunner MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aygedjfaGDSK1zBb8wR9jJoD9hg Subject: Re: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 19:33:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I have prepared a small Python program for generating of RFC 3526 MODP groups. It's using Machin's formula for calculating Pi, trial divisions with small primes and Miller-Rabin primality test to search for primes. It should check all the MODP groups in couple of hours on a modern PC. https://github.com/fedor-brunner/test_RFC3526 -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJTILZeXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4QkVFQ0NBRDcyNzU1RTk2RTQwMzlEQjc2 RTE3NDA5NTQwNTY2M0FEAAoJEG4XQJVAVmOt3LIP/0/7LJf2JML+wcYhMo0Z0HeW GaI9dQoqNhWFCUXlVjKcwpHksHEDcF1EmkT00ByiwZATRAA+88f/oDPPgAVChu4f 1Z6lfxk6AEuLedpE1Cu+Q2mhMB2aIKdWdN+hKvyqn1F1y8d8LxIMF8Ic1UteqIUS pG2tG24iAya+PMrdFgI5awJGpMbbSOSnmvJVEQ0M5i9ARnQyBYGmUZ+Gy5Xlu1n4 VOweeMuM6LUnAOyy+cqpdTnAATPX3+fh+lBhm888v8WfovJS/hBQZD4U3N26t+kI C0KIghinTCqrgOvpxqgNLmx1ot2IaBYGbA4gs/i2oOxS5qKDiwam1Fq6qRsnQELr FwSPRG8T9tkcRz7eQhXdnSSMoj82hKKlH0DOjVLOCxWLl28tOYWlYledC4AtvAtz q5tz+IqvQvPxldeCGlwfrskiD/q9rrzFXDPSrs7m0JA2CHHP0mjbUEHrii+IJ+5M R3aWBQVxaUAuYSR5Kags3NqHsouQYYwhoAqjAUMYM0bUNQtORz0G393GoocNd/qf V8FNHf21Xl6J4rPjum1Q0vy6giXdjwM8At5GKQDuiL/KczcQoUFY9CQpJALbDd65 +9+F0EdqKtm6wTEqDsmySdJvBHem2vFe0vkM5Z71kz/A0uEhh9EK6e9b9cZKzYkH 9Dixvv3LePd8sAA8oB1A =0DfY -----END PGP SIGNATURE----- From nobody Wed Mar 12 12:36:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3171A04D2 for ; Wed, 12 Mar 2014 12:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOcI8Wk8u9-J for ; Wed, 12 Mar 2014 12:36:03 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (agjbgdcfdbgf.dreamhost.com [69.163.253.165]) by ietfa.amsl.com (Postfix) with ESMTP id 107FD1A048E for ; Wed, 12 Mar 2014 12:36:03 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 1578E5405B for ; Wed, 12 Mar 2014 12:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=fWTQFk6yFYB7ZbpQqXyc EvA/cTk=; b=yMGVyh4nihMJykcELcmFIGHtfe+nK0wAEIbGqW6uoXxfihPjyjJ7 SPynX5oLK681AQvaba0KEkXKHrEwGqTltBHJpKAdSU6/ptIvBdbkPtc9dCYW8bhw O5GNr4v5yljw7RRmJ9A2Y+KLr8QwFtPXvCAmHpJMEfNeBKR8KgD5NmE= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id B8F2854055 for ; Wed, 12 Mar 2014 12:35:56 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so11809915wgg.13 for ; Wed, 12 Mar 2014 12:35:55 -0700 (PDT) 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=1rgwDGJHPPhYKH4EE0RegnvnaOwZvlTmKjqDjyb5sHM=; b=FBfRnJyp0VSuQqDtj5E68Kmxj3Jkspc/3sfH6V3LTSSyWlcdusd97IWFEF6x/27Q8m /e2IdwbwZ6I2UXOYP76McLYCWwn/4vXYDBzdO4sHGINY+kcklbgQ79jw9m2qhUiWzJED 0VHzzlysEYyYJQWHkj04lrvJo3Ba7G2sKoFS/o10mvVUpdmvAnnlETNj9i3L3dBcPKJQ y2B4LXiEnSihApATECuxWirI30ABwvUnnZK8+vALpb8N3AaX5nStjTQWaxzJMKM6R6l6 14BfbYbg+MxPRtwemhx/m5si9MWGcfgQF2SajyHjIVbSbdPtT3S9IPROy3Pkq+cK8qF1 HLew== MIME-Version: 1.0 X-Received: by 10.180.77.74 with SMTP id q10mr8896613wiw.39.1394652955383; Wed, 12 Mar 2014 12:35:55 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 12:35:55 -0700 (PDT) In-Reply-To: <5320B4B2.70801@stpeter.im> References: <5320B4B2.70801@stpeter.im> Date: Wed, 12 Mar 2014 14:35:55 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xRhmFiNsLfK3HLPpsEAyjXpgj1s Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Wish List Suggestions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 19:36:04 -0000 On Wed, Mar 12, 2014 at 2:25 PM, Peter Saint-Andre wrote: > On 3/12/14, 1:09 PM, Nico Williams wrote: >>> o Should we get rid of resumption? >> >> >> Why? But we should get rid of resumption without resumption tickets. > > > For all TLS-using application protocols, or mainly for HTTP? For TLS. We're talking about TLS 1.3... > >> Resumption session caches on the server side are very hard to get >> right. > > > All of this is hard to get right. :-) Yes :( Some things add unnecessary complexity. And session resumption tickets are actually a major simplification, therefore we should jettison the old more complex variant. Nico -- From nobody Wed Mar 12 13:29:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CAC1A074A for ; Wed, 12 Mar 2014 13:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 bXKyJK_PLwFn for ; Wed, 12 Mar 2014 13:29:08 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 752B61A068F for ; Wed, 12 Mar 2014 13:29:08 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D26B940455; Wed, 12 Mar 2014 14:29:01 -0600 (MDT) Message-ID: <5320C38D.4060101@stpeter.im> Date: Wed, 12 Mar 2014 14:29:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nico Williams References: <5320B4B2.70801@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LHbgIE9I1RznHP9qyOyJdr43L5c Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Wish List Suggestions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 20:29:10 -0000 On 3/12/14, 1:35 PM, Nico Williams wrote: > On Wed, Mar 12, 2014 at 2:25 PM, Peter Saint-Andre wrote: >> On 3/12/14, 1:09 PM, Nico Williams wrote: >>>> o Should we get rid of resumption? >>> >>> >>> Why? But we should get rid of resumption without resumption tickets. >> >> >> For all TLS-using application protocols, or mainly for HTTP? > > For TLS. We're talking about TLS 1.3... > >> >>> Resumption session caches on the server side are very hard to get >>> right. >> >> >> All of this is hard to get right. :-) > > Yes :( Some things add unnecessary complexity. And session > resumption tickets are actually a major simplification, therefore we > should jettison the old more complex variant. I ask because HTTP is a so-called stateless protocol, whereas in the XMPP world it's natural for the server to hold a lot of state about the client connection. Where I come from, it feels weird for the server to send a bunch of state down the client only to have the client present it again on session resumption. Peter From nobody Wed Mar 12 13:40:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71E91A0644 for ; Wed, 12 Mar 2014 13:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVAGjIbyU4H3 for ; Wed, 12 Mar 2014 13:40:00 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 79ABA1A0496 for ; Wed, 12 Mar 2014 13:40:00 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 895C147424; Wed, 12 Mar 2014 20:39:52 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id B1AB547449; Wed, 12 Mar 2014 20:39:51 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 807A28005C; Wed, 12 Mar 2014 20:39:51 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.104]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 12 Mar 2014 16:39:50 -0400 From: "Salz, Rich" To: Peter Saint-Andre , Nico Williams Date: Wed, 12 Mar 2014 16:39:49 -0400 Thread-Topic: [TLS] TLS 1.3 Wish List Suggestions Thread-Index: Ac8+MctTYfivp3MuSO20N3rmXyu6fwAAR7nw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D5896@USMBX1.msg.corp.akamai.com> References: <5320B4B2.70801@stpeter.im> <5320C38D.4060101@stpeter.im> In-Reply-To: <5320C38D.4060101@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mGv--3Buj-Gu8EIYuDBJUzOoCIU Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Wish List Suggestions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 20:40:02 -0000 > I ask because HTTP is a so-called stateless protocol, whereas in the XMPP= world it's natural for the server to hold a lot of state about the client = connection. Where I come from, it feels weird for the server to send a bunc= h of state down the client only to have the client present it again on sess= ion resumption. Would it feel less weird if you think of it as a distributed cluster of ser= vers? /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Wed Mar 12 13:49:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C0E1A077C for ; Wed, 12 Mar 2014 13:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 U3BxPRiGFNRX for ; Wed, 12 Mar 2014 13:49:52 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 607841A0766 for ; Wed, 12 Mar 2014 13:49:48 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F1B1140455; Wed, 12 Mar 2014 14:49:41 -0600 (MDT) Message-ID: <5320C865.7080800@stpeter.im> Date: Wed, 12 Mar 2014 14:49:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Salz, Rich" , Nico Williams References: <5320B4B2.70801@stpeter.im> <5320C38D.4060101@stpeter.im> <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D5896@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D5896@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H2Nxo5gQN99nnCAgcI75hZK0Z4g Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Wish List Suggestions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 20:49:53 -0000 On 3/12/14, 2:39 PM, Salz, Rich wrote: >> I ask because HTTP is a so-called stateless protocol, whereas in the XMPP world it's natural for the server to hold a lot of state about the client connection. Where I come from, it feels weird for the server to send a bunch of state down the client only to have the client present it again on session resumption. > > Would it feel less weird if you think of it as a distributed cluster of servers? You mean the client is one node in a server cluster? That sounds even weirder. :-) Peter From nobody Wed Mar 12 13:52:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE111A0747 for ; Wed, 12 Mar 2014 13:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KUHJih0-wsp for ; Wed, 12 Mar 2014 13:52:00 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 9C62C1A0664 for ; Wed, 12 Mar 2014 13:52:00 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5D19E481E1; Wed, 12 Mar 2014 20:51:54 +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 51E11481BE; Wed, 12 Mar 2014 20:51:54 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id B193847BD2; Wed, 12 Mar 2014 20:51:53 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.104]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Wed, 12 Mar 2014 16:51:53 -0400 From: "Salz, Rich" To: Peter Saint-Andre , Nico Williams Date: Wed, 12 Mar 2014 16:51:52 -0400 Thread-Topic: [TLS] TLS 1.3 Wish List Suggestions Thread-Index: Ac8+NJmzcqDIETcHTnmUXsQ28QEeTAAACJNA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D58C2@USMBX1.msg.corp.akamai.com> References: <5320B4B2.70801@stpeter.im> <5320C38D.4060101@stpeter.im> <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D5896@USMBX1.msg.corp.akamai.com> <5320C865.7080800@stpeter.im> In-Reply-To: <5320C865.7080800@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/puzjlGyCDxlQ0827nXzYfL89AX0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Wish List Suggestions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 20:52:02 -0000 > You mean the client is one node in a server cluster? That sounds even wei= rder. :-) No, the server is a pool and next time you connect you'll perhaps get a dif= ferent one. This seems to be how twitter works, for example: https://blog.twitter.com/2= 013/forward-secrecy-at-twitter /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Wed Mar 12 14:01:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC14E1A0644 for ; Wed, 12 Mar 2014 14:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 INddptzfgJqZ for ; Wed, 12 Mar 2014 14:01:41 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BEA8E1A074C for ; Wed, 12 Mar 2014 14:01:41 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8878440455; Wed, 12 Mar 2014 15:01:35 -0600 (MDT) Message-ID: <5320CB2E.4020200@stpeter.im> Date: Wed, 12 Mar 2014 15:01:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Salz, Rich" , Nico Williams References: <5320B4B2.70801@stpeter.im> <5320C38D.4060101@stpeter.im> <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D5896@USMBX1.msg.corp.akamai.com> <5320C865.7080800@stpeter.im> <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D58C2@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D58C2@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tZervymQYF-roVtZP_PNOWx4JUE Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Wish List Suggestions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 21:01:42 -0000 On 3/12/14, 2:51 PM, Salz, Rich wrote: >> You mean the client is one node in a server cluster? That sounds even weirder. :-) > > No, the server is a pool and next time you connect you'll perhaps get a different one. Oh yes, many XMPP server implementations are deployed that way at high scale. Peter From nobody Wed Mar 12 14:03:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E265A1A077E for ; Wed, 12 Mar 2014 14:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBsV9BWcLHyl for ; Wed, 12 Mar 2014 14:03:00 -0700 (PDT) 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 F2D7F1A0764 for ; Wed, 12 Mar 2014 14:02:59 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id d10so99544eaj.6 for ; Wed, 12 Mar 2014 14:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DEhOJPLGk4zwmrwMz5aq+lDIXv7mnYVqrLhlL5NUg0U=; b=ZgJ1/8durd7OIzPJebXs/9A+rQr9NEuWi6w89t57Tdu9v15Sjcmsc0h1+1PWFykjDB zIOLvNE1aDLQelKq1ksv0ev+QlV0KIgLsZxbk7eZDU8VpZcRre7DgWTu4kcDPiIel3ZC r97BD33VxLyjbI5ix5laPQOwIMOFJErv2yBPVD/3DOm7YjmPBgQCV4kvmp2zV/d8QIQt jwzminFiVMHuMtArDKr82Ob7A5jQ3vdzLb63mn3FbAU2vtC82rTeiwLlLQ2VzeEWGhyp cwap1HjPM9Z82OgkHKrBaWu+ZLR2mpyLIPutbQKQLhnchQl8IXkDGmoL+rhMlRw6Zd2L HZSQ== X-Received: by 10.14.198.197 with SMTP id v45mr34688977een.9.1394658173380; Wed, 12 Mar 2014 14:02:53 -0700 (PDT) Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id f45sm287561eeg.5.2014.03.12.14.02.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Mar 2014 14:02:52 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: Date: Wed, 12 Mar 2014 23:02:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <532024EF.4060607@polarssl.org> <53205A3F.5080802@fifthhorseman.net> <2643d802-f33b-4caf-b5e1-4df42d59814e@email.android.com> To: Alexandre Anzala-Yamajako X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ISToGz3_znCcVkq3AQI51Icr0j4 Cc: tls@ietf.org Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 21:03:02 -0000 Anonymous cipher suites save not only bandwidth, they also save = calculation.=20 ECDHE_RSA requires a private RSA operation on the server as well as the = ECDH calculation ECDHE alone requires only the ECDH calculation.=20 In many servers the cost of the handshake is a more significant part of = the sizing than the application or the encryption. So that would save a = lot - the same server will be able to handle more clients. However, anonymous cipher suites are very rarely used in practice. = Browsers don=92t implement them at all, and they=92re not the default = for any library. Yoav On Mar 12, 2014, at 3:34 PM, Alexandre Anzala-Yamajako = wrote: > Just out of curisoity, is anyone aware of scenarios where people chose = *_anon suites to save on the bandwidth of sending certificates ? >=20 >=20 > --=20 > Alexandre Anzala-Yamajako >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Mar 12 14:24:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A7C1A074A for ; Wed, 12 Mar 2014 14:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WeGvc-jX135 for ; Wed, 12 Mar 2014 14:24:49 -0700 (PDT) Received: from bacon.lysator.liu.se (vindbrygga.lysator.liu.se [IPv6:2001:6b0:17:f0a0::de]) by ietfa.amsl.com (Postfix) with ESMTP id 23E5F1A073B for ; Wed, 12 Mar 2014 14:24:48 -0700 (PDT) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s2CLObAM012152; Wed, 12 Mar 2014 22:24:37 +0100 (MET) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s2CLOZb7012151; Wed, 12 Mar 2014 22:24:35 +0100 (MET) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: henrick@streamsec.se References: <9A043F3CF02CD34C8E74AC1594475C7372387C9E@uxcn10-6.UoA.auckland.ac.nz> <201403072318.SAA28740@Chip.Rodents-Montreal.ORG> <20140308102142.GA25856@roeckx.be> <42833.1394302378@eng-mail01.juniper.net> <531F8ADF.3060002@fifthhorseman.net> <531FB5DC.1010001@streamsec.se> <53202E8D.9090403@streamsec.se> Date: Wed, 12 Mar 2014 22:24:35 +0100 In-Reply-To: ("Niels =?iso-8859-1?Q?M=F6ller=22's?= message of "Wed, 12 Mar 2014 15:08:05 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UgvLkeiBm7xTZvawbhmhP_RlKcw Cc: ietf-ssh@netbsd.org, IETF TLS WG Subject: Re: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 21:24:52 -0000 nisse@lysator.liu.se (Niels Mller) writes: > 3. The 8192-bit prime definitely seems a bit expensive to generate. I've now ran the updated version of the program on a more high-end pc. For 8192 bits, it completed in about 52 minutes. Output: p = 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb850458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fbecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7d! c90a6c08f4df435c93402849236c3fab4d27c7026c1d4dcb2602646dec9751e763dba37bdf8ff9406ad9e530ee5db382f413001aeb06a53ed9027d831179727b0865a8918da3edbebcf9b14ed44ce6cbaced4bb1bdb7f1447e6cc254b332051512bd7af426fb8f401378cd2bf5983ca01c64b92ecf032ea15d1721d03f482d7ce6e74fef6d55e702f46980c82b5a84031900b1c9e59e7c97fbec7e8f323a97a7e36cc88be0f1d45b7ff585ac54bd407b22b4154aacc8f6d7ebf48e1d814cc5ed20f8037e0a79715eef29be32806a1d58bb7c5da76f550aa3d8a1fbff0eb19ccb1a313d55cda56c9ec2ef29632387fe8d76e3c0468043e8f663f4860ee12bf2d5b0b7474d6e694f91e6dbe115974a3926f12fee5e438777cb6a932df8cd8bec4d073b931ba3bc832b68d9dd300741fa7bf8afc47ed2576f6936ba424663aab639c5ae4f5683423b4742bf1c978238f16cbe39d652de3fdb8befc848ad922222e04a4037c0713eb57a81a23f0c73473fc646cea306b4bcbc8862f8385ddfa9d4b7fa2c087e879683303ed5bdd3a062b3cf5b3a278a66d2a13f83f44f82ddf310ee074ab6a364597e899a0255dc164f31cc50846851df9ab48195ded7ea1b1d510bd7ee74d73faf36bc31ecfa268359046f4eb879f924009438b481c6cd7889a002ed5ee382bc9190da6fc026e47955! 8e4475677e9aa9e3050e2765694dfc81f56e880b96e7160c980dd98edd3dff! fffffffffffffff k = 4743157 elapsed time 3133.28s Which after a cursory look appears to agree with https://www.rfc-editor.org/rfc/rfc3526.txt (I guess the 47473157 vs 4743158 is an off-by-one error in my code. Does the spec's brackets in in "[2^8062 pi]" denote floor or round-to-nearest? Regards, /Niels -- Niels Mller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From nobody Wed Mar 12 14:30:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7F21A0644 for ; Wed, 12 Mar 2014 14:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 ItcpVAdmmlqi for ; Wed, 12 Mar 2014 14:30:50 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 289F91A0664 for ; Wed, 12 Mar 2014 14:30:50 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 43280F986; Wed, 12 Mar 2014 17:30:41 -0400 (EDT) Message-ID: <5320D202.4070807@fifthhorseman.net> Date: Wed, 12 Mar 2014 17:30:42 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: =?UTF-8?B?TmllbHMgTcO2bGxlcg==?= , henrick@streamsec.se References: <9A043F3CF02CD34C8E74AC1594475C7372387C9E@uxcn10-6.UoA.auckland.ac.nz> <201403072318.SAA28740@Chip.Rodents-Montreal.ORG> <20140308102142.GA25856@roeckx.be> <42833.1394302378@eng-mail01.juniper.net> <531F8ADF.3060002@fifthhorseman.net> <531FB5DC.1010001@streamsec.se> <53202E8D.9090403@streamsec.se> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="moJJCpL37U7aBEQ9BVXbUMPrrmlnvl3n4" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/r-xPo29B_v9UrqIvA4M0hkW9lC4 Cc: ietf-ssh@netbsd.org, IETF TLS WG Subject: Re: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 21:30:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --moJJCpL37U7aBEQ9BVXbUMPrrmlnvl3n4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/12/2014 05:24 PM, Niels M=C3=B6ller wrote: > nisse@lysator.liu.se (Niels M=C3=B6ller) writes: >=20 >> 3. The 8192-bit prime definitely seems a bit expensive to generate. >=20 > I've now ran the updated version of the program on a more high-end pc. > For 8192 bits, it completed in about 52 minutes. Output: >=20 > p =3D 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc7= 4020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d= 6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5a= e9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd= 24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f17= 46c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c= 52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aaac42dad331= 70d04507a33a85521abdf1cba64ecfb850458dbef0a8aea71575d060c7db3970f85a6e1e4= c7abf5ae8cdb0933d71e8c94e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d876027= 33ec86a64521f2b18177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab31= 43db5bfce0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186= af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fbecaa628= 7c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2d7afb81bdd76217= 0481cd0069127d5b05aa993b4ea988d8fddc186ffb7d! > c90a6c08f4df435c93402849236c3fab4d27c7026c1d4dcb2602646dec9751e763dba3= 7bdf8ff9406ad9e530ee5db382f413001aeb06a53ed9027d831179727b0865a8918da3edb= ebcf9b14ed44ce6cbaced4bb1bdb7f1447e6cc254b332051512bd7af426fb8f401378cd2b= f5983ca01c64b92ecf032ea15d1721d03f482d7ce6e74fef6d55e702f46980c82b5a84031= 900b1c9e59e7c97fbec7e8f323a97a7e36cc88be0f1d45b7ff585ac54bd407b22b4154aac= c8f6d7ebf48e1d814cc5ed20f8037e0a79715eef29be32806a1d58bb7c5da76f550aa3d8a= 1fbff0eb19ccb1a313d55cda56c9ec2ef29632387fe8d76e3c0468043e8f663f4860ee12b= f2d5b0b7474d6e694f91e6dbe115974a3926f12fee5e438777cb6a932df8cd8bec4d073b9= 31ba3bc832b68d9dd300741fa7bf8afc47ed2576f6936ba424663aab639c5ae4f5683423b= 4742bf1c978238f16cbe39d652de3fdb8befc848ad922222e04a4037c0713eb57a81a23f0= c73473fc646cea306b4bcbc8862f8385ddfa9d4b7fa2c087e879683303ed5bdd3a062b3cf= 5b3a278a66d2a13f83f44f82ddf310ee074ab6a364597e899a0255dc164f31cc50846851d= f9ab48195ded7ea1b1d510bd7ee74d73faf36bc31ecfa268359046f4eb879f924009438b4= 81c6cd7889a002ed5ee382bc9190da6fc026e47955! > 8e4475677e9aa9e3050e2765694dfc81f56e880b96e7160c980dd98edd3dff! > fffffffffffffff > k =3D 4743157 > elapsed time 3133.28s >=20 > Which after a cursory look appears to agree with > https://www.rfc-editor.org/rfc/rfc3526.txt (I guess the 47473157 vs > 4743158 is an off-by-one error in my code. Does the spec's brackets in > in "[2^8062 pi]" denote floor or round-to-nearest? i was using floor for my calculations, not round-to-nearest. --dkg --moJJCpL37U7aBEQ9BVXbUMPrrmlnvl3n4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTINICXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcC18P/j+zYG/Nvs0nqD+W/2w/OAQL LY4T3BHbwpYLexhBfFkltpWuHI+nXVf0n3PZl7niJ90jWdxmFEjWh9TsDi8eMt1W FgWwUtH+gNz5MMINht78KKrFN2HnZ8IujE+NtAsUtZGQOGbI9yV6OCq0x09J2gpW 02UxrKpy7fOcY6gkpZPOJuN/5La9N3BGW7Za4TcpvbYthVqLKuDMoQsF0rvqqJu2 ZVZw9hNT57Gpgkf6dnaOai4ubZaPnVV8niNOsZeVXuLF6Jip3Tdy4i6GuENY6UM/ Q9GoLQlQuboZELFFYo5bLY3KdKQdWojzdJ4dKmXsloyheyhx6PJIj+Of3Vk+1yvL TJIAS3bP4zG0SmdcbyjYSpMk18SQxJtMJ1RJOwjCN6vj220js72RUcHpcJyzFfqX Z7CTqr/s9WfXUU1ri5CitkwE35RD7Z1L7cvck/rYbpGRDXkGOLE/5GedcGjrhKdd Mc814DbfJamrX/qPXhF4DTbJiXGt+Sh0+J6lXv2vR1fjGRrJ3lwGITZXP6M05ZTG nUfd32wvbsMra6mpwxn5NWBcOo6V2AHTkTGPNZqWXYgfxaocTIus4FbmQLEdkwrR ZxXhBZdO0YZuiwIi23gmKkMr/pJ5o7bkqGwbFK1lKkuJYshwdiFcczwShOMJFmWg 7ama2/ZySXddjeuLe3nE =SVTc -----END PGP SIGNATURE----- --moJJCpL37U7aBEQ9BVXbUMPrrmlnvl3n4-- From nobody Wed Mar 12 14:42:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776321A077F for ; Wed, 12 Mar 2014 14:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] 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 6TTYnA40Jkas for ; Wed, 12 Mar 2014 14:42:23 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (unknown [69.163.253.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEF81A076A for ; Wed, 12 Mar 2014 14:42:23 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 4773C350082 for ; Wed, 12 Mar 2014 14:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=1pSVOoOuJUdTCsbYGuG+ t81N40s=; b=BqFWiBq+Jo7uCUlLkV6wlCO6pt6QvmA+7uHrqs+K5U9F111qKkBS PxWZPThRa6Y8SUl8fqjLh30cmUlUTnbsjrwdTGnjBN9O9/9mKTsI9qGyqnNs5+9j DZmyp/uzPqXFuvkpLQlpcVeKib4A0GYc685AXKMX3CKT+ZOgBi6mCKw= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id EF3FF35007F for ; Wed, 12 Mar 2014 14:42:16 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so101306wgh.28 for ; Wed, 12 Mar 2014 14:42:15 -0700 (PDT) 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=frIBXTjef1Xc2PldljdDuDCv14cPa6YcpMqJ/5M47Us=; b=F//ZFm2CQBLnVSluylT71gK6Wo3zPxKx7+lcJFNUcJDV60qIGCQEHFuAabfhqz5L1S O3xJ9AYc7Pz9giUJTy8DxRWr2ZHxI1mAIObgsJT+grZUao5CeIh8Xf3nC37vPlPqtoQ9 f6AV2JLGhWXhdkMg6mmwTRrY8jD2pL8MrDICoDpFcomTOsTBzLodspBJ+yubCJPrxl59 xSwzv5lDrzWvFielv1L98cNdHyI15gXhm8pzoxFHllwtCRjcR3jbExgADUcsHb5WkAoj JbSlkb92IZYTiVBAKsU6EzXbFw369z+1D4i0GZfdj9gPvihuZBktVn8Acd5JxHBTNtg+ JZZA== MIME-Version: 1.0 X-Received: by 10.180.72.230 with SMTP id g6mr9452236wiv.1.1394660535664; Wed, 12 Mar 2014 14:42:15 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 14:42:15 -0700 (PDT) In-Reply-To: <5320C38D.4060101@stpeter.im> References: <5320B4B2.70801@stpeter.im> <5320C38D.4060101@stpeter.im> Date: Wed, 12 Mar 2014 16:42:15 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/e4hoo5XonXd1XM_Q8HHHe_4oR18 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Wish List Suggestions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 21:42:24 -0000 On Wed, Mar 12, 2014 at 3:29 PM, Peter Saint-Andre wrote: > I ask because HTTP is a so-called stateless protocol, whereas in the XMPP HTTP is stateless, but apps that use HTTP don't have to be (cookies!), and TLS doesn't have to be (sessions! connections!). In any case, if statelessness is what you're after, then TLS session resumption tickets is what you want, and deprecating the old form of session resumption should be something you should really want. To be fair clients don't have to be willing to resume sessions, and servers don't have to offer resumption. Of either type. So it's already possible for clients and servers to only implement session resumption tickets, or not at all. But session resumption with session resumption tickets is a *good* thing, a great optimization (supposing that its use is not itself revealing of important information to passive attackers). > world it's natural for the server to hold a lot of state about the client > connection. Where I come from, it feels weird for the server to send a bunch > of state down the client only to have the client present it again on session > resumption. I don't see anything weird about that. Nico -- From nobody Wed Mar 12 14:51:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9221A0768 for ; Wed, 12 Mar 2014 14:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uda3nhU0P7MU for ; Wed, 12 Mar 2014 14:50:57 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (smtp01.srv.cs.cmu.edu [128.2.217.200]) by ietfa.amsl.com (Postfix) with ESMTP id B61F01A0685 for ; Wed, 12 Mar 2014 14:50:57 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s2CLomlT012386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 12 Mar 2014 17:50:49 -0400 (EDT) Message-ID: <1394661048.25748.40.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Niels =?ISO-8859-1?Q?M=F6ller?= Date: Wed, 12 Mar 2014 17:50:48 -0400 In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C7372387C9E@uxcn10-6.UoA.auckland.ac.nz> <201403072318.SAA28740@Chip.Rodents-Montreal.ORG> <20140308102142.GA25856@roeckx.be> <42833.1394302378@eng-mail01.juniper.net> <531F8ADF.3060002@fifthhorseman.net> <531FB5DC.1010001@streamsec.se> <53202E8D.9090403@streamsec.se> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 8bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.200 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nLk96PeIrEl6SSMIs9ZQDDgQnj8 Cc: IETF TLS WG , ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 21:51:01 -0000 On Wed, 2014-03-12 at 22:24 +0100, Niels Möller wrote: > nisse@lysator.liu.se (Niels Möller) writes: > > > 3. The 8192-bit prime definitely seems a bit expensive to generate. > > I've now ran the updated version of the program on a more high-end pc. > For 8192 bits, it completed in about 52 minutes. Output: > > p = 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb850458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fbecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb! 7d! > c90a6c08f4df435c93402849236c3fab4d27c7026c1d4dcb2602646dec9751e763dba37bdf8ff9406ad9e530ee5db382f413001aeb06a53ed9027d831179727b0865a8918da3edbebcf9b14ed44ce6cbaced4bb1bdb7f1447e6cc254b332051512bd7af426fb8f401378cd2bf5983ca01c64b92ecf032ea15d1721d03f482d7ce6e74fef6d55e702f46980c82b5a84031900b1c9e59e7c97fbec7e8f323a97a7e36cc88be0f1d45b7ff585ac54bd407b22b4154aacc8f6d7ebf48e1d814cc5ed20f8037e0a79715eef29be32806a1d58bb7c5da76f550aa3d8a1fbff0eb19ccb1a313d55cda56c9ec2ef29632387fe8d76e3c0468043e8f663f4860ee12bf2d5b0b7474d6e694f91e6dbe115974a3926f12fee5e438777cb6a932df8cd8bec4d073b931ba3bc832b68d9dd300741fa7bf8afc47ed2576f6936ba424663aab639c5ae4f5683423b4742bf1c978238f16cbe39d652de3fdb8befc848ad922222e04a4037c0713eb57a81a23f0c73473fc646cea306b4bcbc8862f8385ddfa9d4b7fa2c087e879683303ed5bdd3a062b3cf5b3a278a66d2a13f83f44f82ddf310ee074ab6a364597e899a0255dc164f31cc50846851df9ab48195ded7ea1b1d510bd7ee74d73faf36bc31ecfa268359046f4eb879f924009438b481c6cd7889a002ed5ee382bc9190da6fc026e479! 55! > 8e4475677e9aa9e3050e2765694dfc81f56e880b96e7160c980dd98edd3dff! > fffffffffffffff > k = 4743157 > elapsed time 3133.28s > > Which after a cursory look appears to agree with > https://www.rfc-editor.org/rfc/rfc3526.txt (I guess the 47473157 vs > 4743158 is an off-by-one error in my code. Does the spec's brackets in > in "[2^8062 pi]" denote floor or round-to-nearest? Neither 2412 nor 3526 says what they mean by that notation, but I'm assuming floor. However, in that case your result agrees with the spec. The value given in the spec is 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] + 4743158 } This can be rewritten as: 2^8192 - 2^8128 + 2^64 * { [2^8062 pi] + 4743157 } + 2^64 - 1 The first two terms give the high-order 64 bits (all 1). The next term gives the middle bits, and agrees with your result. The last two terms give the low-order 64 bits. -- Jeff From nobody Wed Mar 12 15:09:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3281A079D for ; Wed, 12 Mar 2014 15:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lMwTuyejLLc for ; Wed, 12 Mar 2014 15:09:04 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 793201A0764 for ; Wed, 12 Mar 2014 15:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1394662138; x=1426198138; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=cmqnyQ4ZtW8BPXaJH5P01+cfQjFYjtLg5F6J9yEKYZc=; b=kxVN/eM/Ovp3aBMWzuZt186T9LROO543hznUV/1W/TgUTHsedowhmbWW otmZfjUpyI9IikUaSZwNudfMZFAAHBEwujlZpRZ6tibZTz9MCETIlNOOx D6/qBibSzXlFDYf1pBt2vuLf8OPIwVoC0FM9FLLOoTKIQSGJyUqDfIEQx c=; X-IronPort-AV: E=Sophos;i="4.97,641,1389697200"; d="scan'208";a="239227251" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 13 Mar 2014 11:08:56 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Thu, 13 Mar 2014 11:08:56 +1300 From: Peter Gutmann To: "" , "ietf-ssh@netbsd.org" Thread-Topic: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] Thread-Index: Ac8+P6khvKF7r+7sSbqbCVajK6GYkw== Date: Wed, 12 Mar 2014 22:08:55 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C737238AAAF@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7WHR5rhFdOL2c2Hq1YQXwtmlfjU Subject: Re: [TLS] MODP group modulus derivation [was: Re: I can has SHA-1 hashes for RFC 2409/3526 MODP groups?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2014 22:09:09 -0000 Daniel Kahn Gillmor writes:=0A= =0A= >It's not clear to me that there is any advantage in a DH key exchange to= =0A= >using the RFC 5114 discrete log groups.=0A= =0A= There's actually an enormous disadvantage to using those groups, the RFC 35= 26=0A= and earlier MODP groups set the generator to 2, which is quite efficient to= =0A= work with. RFC 5114 uses a generator of the same size as the prime, which = is=0A= stunningly inefficient (I've referred to the 5114 groups as the "WTF groups= "=0A= in code in the past). I have no idea why the RFC would choose such an awfu= l=0A= generator...=0A= =0A= Peter.=0A= =0A= From nobody Wed Mar 12 17:32:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199331A07BB for ; Wed, 12 Mar 2014 17:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3HIo63rC14a for ; Wed, 12 Mar 2014 17:32:45 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 1B58B1A07A6 for ; Wed, 12 Mar 2014 17:32:44 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.14.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6B599509B6; Wed, 12 Mar 2014 20:32:32 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <532081F3.1080608@stpeter.im> Date: Thu, 13 Mar 2014 11:32:30 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <531F9443.1000002@cs.tcd.ie> <532080AD.6080907@cs.tcd.ie> <532081F3.1080608@stpeter.im> To: Peter Saint-Andre , Eric Rescorla X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hkT5X5xYr9siS26OVuiMsZRd39c Cc: "tls@ietf.org" Subject: Re: [TLS] TLS chairing changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 00:32:48 -0000 On 13 Mar 2014, at 2:49 am, Peter Saint-Andre = wrote: > IMHO, basically starting from RFC 5246 will improve transparency. = Speaking of which, let me send the XML-ized version I have to Eric. I have a markdown-ized version nearing completion; all that needs to be = done is converting some of the references and a bit of cleanup. EKR, should I continue that, or do you want to go XML? If I slap it on = github and get help from a few people, it shouldn't take long. Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Wed Mar 12 18:11:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7F51A07E2 for ; Wed, 12 Mar 2014 18:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b15I8kC3_DV4 for ; Wed, 12 Mar 2014 18:10:58 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D6A101A07E5 for ; Wed, 12 Mar 2014 18:10:37 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id a41so362679yho.18 for ; Wed, 12 Mar 2014 18:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=B7w2TJYHV4n4kEMO1zx2XShZbdZEtFRV9lPIgyOMGtU=; b=UQQYBNL73C0CGNbMRfO5yE7hpFduynOOjZz8Wtvoeku0XnqPwuI+K5IUQakuxK0zlw K4mYdArD0rB4aDoXsq1vgjexkBvaRZmvvT8SavohGEJuI/iW+koscpFPywc0VUU98Epb kGXGOe2oP9ifUwqTyNLj3BFCy/r93CsD5gxBbB/Nc3x2anEwMs8Biifh0wEeghM03QcD 8e8mb+a6autikPfd6FGZBDG8y1EbUUdd8LOk3nKz0v00/m7yBFzZTpxA7lsWmwgXMLL9 imWeYNRwgTgfgUSP0mIM3RApIXe1fiDrc2tsTQmeVvZ1icikRGG7MBMQ+ZT5QyJb2T71 3E1g== MIME-Version: 1.0 X-Received: by 10.236.60.68 with SMTP id t44mr723585yhc.47.1394673031390; Wed, 12 Mar 2014 18:10:31 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Wed, 12 Mar 2014 18:10:31 -0700 (PDT) Date: Wed, 12 Mar 2014 18:10:31 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4mtTYtRTcnuQzck0PSPtd6Eu82c Subject: [TLS] Thoughts on TLS 1.3 cryptography performance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 01:11:01 -0000 Dear all, Below are some thoughts about the TLS 1.3 cryptography, based on actual performance measurements together with information about what is actually offered and new research. It also addresses some issues I have with the 1-RTT handshake currently proposed. Currently a state-of-the-art handshake involves 2 exponentiations and a signature on the server side and 2 exponentiations on the client side and a verification. One is fixed base, the other variable base. On haswell the fastest ECDHE agreement takes 45,468 cycles, using a GLS curve. Curve25519 weighs in at 162,460 cycles. These are medians. nistp256 would be in the neighborhood of efp256s, at 273,656 cycles, and the key generation for ECDSA signatures with P256 weighs in at 253,307. (Key generation can use precomputed multiples). This pattern holds for almost all architectures. Recent research gets 72,220 cycles using genus 2 curves: https://eprint.iacr.org/2014/134.pdf. Now, you may wonder why you've never heard of GLS, and the reason is that there is a slight loss of security from the endomorphisms. Point counting on surfaces is a pain, so that's why this is new work. In the land of signatures life is a bit harder. ECDSA validation for P256 takes 850,000 cycles, probably because multiexponentiation wasn't used. Signing takes 373,486 cycles. Even Ed25519 takes 68,552 cycles to sign and 206,886 to verify. What about RSA? Signing with a 1024 bit key takes 1,279,440cycles. I went and validated these numbers will OpenSSL speed on my machine. I can sign with ECDSA P256 ten times as fast as RSA 2048. There is a reason every heavily loaded server is moving to ECDSA_ECDHE as quickly as possible. However, we can do better. The trick is to note that the only time a signature needs to be generated is when the data it protects changes, and the only time it needs to be checked is when you forget whether what it was protecting was protected by it. Therefore, if we have the server send g^a, g^x, and the client g^c, g^y, and compute the premaster secret using the so-called "triple DH" H(g^(ay) |g^(cx) |g^(xy)), so long as the client remembers g^a, it doesn't need to check for a signature. And so long as the server doesn't change g^a, it doesn't need to recompute a signature. (Hashing in the transcript should be done, but I think the Premaster->Master transformation does that?) The extra work done is two exponentiations, replacing a signature generation. This is a slight loss if you are using ECDSA and replace it with ECDHE P256, but with Curve25519 replacing ECDSA it's a win. Furthermore, if the client recalls g^a it doesn't need to ask for a certificate, and we have a 1-RTT handshake, with obvious fallback to a negotiation if the group is wrong or the client wants to see the certificate for g^a again. Asking for the certificate can take place over the secure channel established If we don't mind licensing HMQV we can use that, or remove the g^(xy) if we want PFS so long as the client generated g^c randomly and forgot what c was. This adds a lot more performance by removing an exponentiation. Thanks to Dan Brown for pointing out that HMQV continues to exist on the CFRG list. End of the day, TLS 1.3 won't be adopted because it's more secure: look at TLS 1.0 vs. TLS 1.1 on the SSL Observatory. It will be adopted because it is faster and reduces load on servers, and we should do our best to make sure it is also more secure, simpler to implement well, and includes more of the necessary extension drafts then TLS 1.2 currently does. Lastly, we should strongly consider requiring that miTLS be updated in line with the TLS 1.3 spec. We finally have mechanical validation of security: we shouldn't lose it. Sincerely, Watson Ladd From nobody Wed Mar 12 18:42:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA221A07F5 for ; Wed, 12 Mar 2014 18:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 zW9RiqItSZC5 for ; Wed, 12 Mar 2014 18:42:08 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id D9E9D1A082B for ; Wed, 12 Mar 2014 18:42:05 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2B8C910632; Wed, 12 Mar 2014 21:42:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=kEjJdqaCSIp2 F3BqaU2c22cd9TQ=; b=oacvvKPi8/tr8hzRvUMM6Gr7JeU2aCgsXacO1c7j3tdD Zqk5LispeRE1uf3vtDfhzRLSLp2knmG5LtorZF676MBK/BOax6AJq9jQkBbj1UpD EpeDw5mlajfdf3xVACMxbSuLVMF5Dt/ixthIWaJO9KW32PhRyWWs/RifarM2eio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=KaIoMM wRinIILdr4sM5bpC3cvNgIGeEH6TsiVYOtY9Fae1xG9ft9EKBH0O93zK7Y9+Y2Oz iw43G/JkesBPcbgewPPZrZ87hA8mpqJSVlXRALXH6I6kvigko5LZ0cB02ju93IML VfyvZDH/EfVZxLupTp3s4UntHSIJ2hCg4qm04= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 223A610630; Wed, 12 Mar 2014 21:42:00 -0400 (EDT) Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 787451062F; Wed, 12 Mar 2014 21:41:59 -0400 (EDT) Message-ID: <53210CE4.30003@pobox.com> Date: Wed, 12 Mar 2014 18:41:56 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Watson Ladd References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: AB241162-AA50-11E3-A478-873F0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tush6ms9pUTqhUkvwPocG725OoM Cc: "tls@ietf.org" Subject: [TLS] Version negotiation (was: Thoughts on TLS 1.3 cryptography performance) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 01:42:10 -0000 Watson Ladd wrote: > Dear all, > Below are some thoughts about the TLS 1.3 cryptography.... Is the plan to send client version { 0x03 0x04 } and continue to be subject to downgrade attacks, version intolerance, etc. that plague browsers today? Or is there some other way to signify support for version 1.3? Mike From nobody Wed Mar 12 18:49:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6FD1A0844 for ; Wed, 12 Mar 2014 18:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcTbSoHhED73 for ; Wed, 12 Mar 2014 18:48:56 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 430AA1A0837 for ; Wed, 12 Mar 2014 18:48:56 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hm4so459434wib.13 for ; Wed, 12 Mar 2014 18:48:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=h5GSKout/ouishw7qA0pnw4hYpTSDB6O6InsFAQ3F60=; b=aaXwDZqY4isOo2yxxSjZNDwX+1iKL33xouD2QS6zLPk9BlqV0sXsRWY+g7M5DKOU/C 81kbwmT9875wIVfOb+/IoVdVKPg5wfBnW6h4U+RLcpHUxvzbiVE+EsGCqeqn9rqRqZM0 P0VhEFq356fgsKOQm8syyM7IjSypD/gTSnbM4rouz9uoM42LUjvQ6/tdtcQxXvBk3tqI 8AweawwmmbiPJL9//HGAAOiCw/QJ0hc5OfZzxDOP69jgw1lvpKZO6qWFv7tq2nvDRXn/ h20ysOw+nOl8jCqXWwaOG6FnA7ODgWDsV75JSQ2gVgxy7LubJ+kPR7RN6sr9yBUSnHPH JbrQ== X-Gm-Message-State: ALoCoQl5kksozqYMr8TExGFCjf7bMKcMJRN8aaT8XFT+SvnY1vt6wUZsLiFKbDSYS2Mo+GRZA120 X-Received: by 10.180.101.40 with SMTP id fd8mr965757wib.1.1394675329508; Wed, 12 Mar 2014 18:48:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 12 Mar 2014 18:48:09 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <53210CE4.30003@pobox.com> References: <53210CE4.30003@pobox.com> From: Eric Rescorla Date: Wed, 12 Mar 2014 18:48:09 -0700 Message-ID: To: "Michael D'Errico" Content-Type: multipart/alternative; boundary=f46d041826c697c56c04f47327a1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gDivOb04cTKaOYhy2DX2Wp8vXFU Cc: "tls@ietf.org" Subject: Re: [TLS] Version negotiation (was: Thoughts on TLS 1.3 cryptography performance) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 01:48:58 -0000 --f46d041826c697c56c04f47327a1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 12, 2014 at 6:41 PM, Michael D'Errico wrote: > Watson Ladd wrote: > >> Dear all, >> Below are some thoughts about the TLS 1.3 cryptography.... >> > > Is the plan to send client version { 0x03 0x04 } and continue to be > subject to downgrade attacks, Well, we need to address the downgrade attack problem in any case, and so I was assuming any solution that worked for TLS 1.2 would work for 1.3. version intolerance, etc. that plague > browsers today? Or is there some other way to signify support for > version 1.3? > It seems to me that using the existing version selection mechanism is the default choice, but certainly this is something that in principle the WG could decide to change. -Ekr Mike > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d041826c697c56c04f47327a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 12, 2014 at 6:41 PM, Michael D'Errico <mike-list= @pobox.com> wrote:
Watson Ladd wrote:
Dear all,
Below are some thoughts about the TLS 1.3 cryptography....

Is the plan to send client version { 0x03 0x04 } and continue to be
subject to downgrade attacks,

Well, we need= to address the downgrade attack problem in any case,
and so I wa= s assuming any solution that worked for TLS 1.2 would
work for 1.= 3.


version intol= erance, etc. that plague
browsers today? =A0Or is there some other way to signify support for
version 1.3?

It seems to me that using = the existing version selection mechanism is
the default choice, b= ut certainly this is something that in principle
the WG could dec= ide to change.

-Ekr

Mike

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

--f46d041826c697c56c04f47327a1-- From nobody Wed Mar 12 19:27:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BC51A087E for ; Wed, 12 Mar 2014 19:27:44 -0700 (PDT) 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_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 0gUBXA34bUxF for ; Wed, 12 Mar 2014 19:27:41 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id ADFEA1A087C for ; Wed, 12 Mar 2014 19:27:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,643,1389762000"; d="scan'208";a="2271610" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 12 Mar 2014 22:27:35 -0400 Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([::1]) with mapi id 14.02.0247.003; Wed, 12 Mar 2014 22:27:34 -0400 From: Santosh Chokhani To: Watson Ladd , "tls@ietf.org" Thread-Topic: [TLS] Thoughts on TLS 1.3 cryptography performance Thread-Index: AQHPPlkYoKsO5gFkJUqYPyc9vl3tPZreSnsQ Date: Thu, 13 Mar 2014 02:27:34 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E8113916F48E@scygexch10.cygnacom.com> References: 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.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Biclr22htrYEi8v2P7Ge80d42HE Subject: Re: [TLS] Thoughts on TLS 1.3 cryptography performance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 02:27:44 -0000 Does your calculation include certification path verification and associate= d public key operations? Note that certification path verification will al= so entail revocation (CRL or OCSP certificate and OCSP response) verificati= on. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Watson Ladd Sent: Wednesday, March 12, 2014 9:11 PM To: tls@ietf.org Subject: [TLS] Thoughts on TLS 1.3 cryptography performance Dear all, Below are some thoughts about the TLS 1.3 cryptography, based on actual per= formance measurements together with information about what is actually offe= red and new research. It also addresses some issues I have with the 1-RTT h= andshake currently proposed. Currently a state-of-the-art handshake involves 2 exponentiations and a sig= nature on the server side and 2 exponentiations on the client side and a ve= rification. One is fixed base, the other variable base. On haswell the fastest ECDHE agreement takes 45,468 cycles, using a GLS cur= ve. Curve25519 weighs in at 162,460 cycles. These are medians. nistp256 would be in the neighborhood of efp256s, at 273,656 cycles, and th= e key generation for ECDSA signatures with P256 weighs in at 253,307. (Key = generation can use precomputed multiples). This pattern holds for almost al= l architectures. Recent research gets 72,220 cycles using genus 2 curves: https://eprint.iacr.org/2014/134.pdf. Now, you may wonder why you've never= heard of GLS, and the reason is that there is a slight loss of security fr= om the endomorphisms. Point counting on surfaces is a pain, so that's why t= his is new work. In the land of signatures life is a bit harder. ECDSA validation for P256 takes 850,000 cycles, probably because multiexponentiation wasn't used= . Signing takes 373,486 cycles. Even Ed25519 takes 68,552 cycles to sign an= d 206,886 to verify. What about RSA? Signing with a 1024 bit key takes 1,279,440cycles. I went and validated these numbers will OpenSSL speed on my machine. I can = sign with ECDSA P256 ten times as fast as RSA 2048. There is a reason every= heavily loaded server is moving to ECDSA_ECDHE as quickly as possible. However, we can do better. The trick is to note that the only time a signature needs to be generated i= s when the data it protects changes, and the only time it needs to be check= ed is when you forget whether what it was protecting was protected by it. Therefore, if we have the server send g^a, g^x, and the client g^c, g^y, an= d compute the premaster secret using the so-called "triple DH" H(g^(ay) |g^(cx) |g^(xy)), so long as the client remembers g^a, it doesn't = need to check for a signature. And so long as the server doesn't change g^a= , it doesn't need to recompute a signature. (Hashing in the transcript shou= ld be done, but I think the Premaster->Master transformation does that?) The extra work done is two exponentiations, replacing a signature generatio= n. This is a slight loss if you are using ECDSA and replace it with ECDHE P= 256, but with Curve25519 replacing ECDSA it's a win. Furthermore, if the client recalls g^a it doesn't need to ask for a certifi= cate, and we have a 1-RTT handshake, with obvious fallback to a negotiation= if the group is wrong or the client wants to see the certificate for g^a a= gain. Asking for the certificate can take place over the secure channel est= ablished If we don't mind licensing HMQV we can use that, or remove the g^(xy) if we= want PFS so long as the client generated g^c randomly and forgot what c wa= s. This adds a lot more performance by removing an exponentiation. Thanks t= o Dan Brown for pointing out that HMQV continues to exist on the CFRG list. End of the day, TLS 1.3 won't be adopted because it's more secure: look at TLS 1.0 vs. TLS 1.1 on the SSL Observatory. It will be adopted beca= use it is faster and reduces load on servers, and we should do our best to = make sure it is also more secure, simpler to implement well, and includes m= ore of the necessary extension drafts then TLS 1.2 currently does. Lastly, we should strongly consider requiring that miTLS be updated in line= with the TLS 1.3 spec. We finally have mechanical validation of security: we shouldn't lose it. Sincerely, Watson Ladd _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Wed Mar 12 20:00:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646001A0889 for ; Wed, 12 Mar 2014 20:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cUn6cw38K5y for ; Wed, 12 Mar 2014 20:00:08 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) by ietfa.amsl.com (Postfix) with ESMTP id 02CBD1A088C for ; Wed, 12 Mar 2014 20:00:06 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 142so1195940ykq.0 for ; Wed, 12 Mar 2014 20:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bnv2CFYnvtdwl66/j9BoFDajTQ1n9iKFDbxK8ZyPPJ0=; b=CVooMbhBJuUmGCGYShfgi+K0DI/xgOnJhxdcLM4aBDdFd5RmODGWJ0kv5w+RSG1mlG gejfK11U4KHdTdQQ4Nx/cbNcYbH3Vn8IRw14f8DkXl7KNcKE3Rzs9FwR+vxlGFt6OofG Y6FpWrrpzP23CEFbEXlMKvukZqFlsC+PcQQNaQnkLnYzxyqj8lQSKEaWZwhsuwCUkALP RMwwJEQDJrg/ko6ms5k7Dg7fdU+SEb2xT9tzz5fhECGe8ZWtnF1cbZfegMBVDElrWKhG 0c+MlxD2bLAI6w2Nkn0RVltVJ33sIZbfM7xbQwNuc1KKv2VDDb89/kBoBCoD66QX2Vra DUQA== MIME-Version: 1.0 X-Received: by 10.236.123.38 with SMTP id u26mr1287882yhh.93.1394679600611; Wed, 12 Mar 2014 20:00:00 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Wed, 12 Mar 2014 20:00:00 -0700 (PDT) In-Reply-To: <4262AC0DB9856847A2D00EF817E8113916F48E@scygexch10.cygnacom.com> References: <4262AC0DB9856847A2D00EF817E8113916F48E@scygexch10.cygnacom.com> Date: Wed, 12 Mar 2014 20:00:00 -0700 Message-ID: From: Watson Ladd To: Santosh Chokhani Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lNG6pR_Dw2c-vwPxZl9vtS7IX-A Cc: "tls@ietf.org" Subject: Re: [TLS] Thoughts on TLS 1.3 cryptography performance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 03:00:09 -0000 On Wed, Mar 12, 2014 at 7:27 PM, Santosh Chokhani wrote: > Does your calculation include certification path verification and associated public key operations? Note that certification path verification will also entail revocation (CRL or OCSP certificate and OCSP response) verification. You raise a deeply interesting point: if you batch verify, calculation is cheaper. However, neither RSA nor ECDSA can be batch verified. Schnorr can, but was patented, and Schnorr wanted to get paid, which is why it isn't used in X509. Furthermore, the cost of signing is the real issue, and the entire path verification can be cached. Even if the client has to do a lot of verification of OCSP responses anyway, saving server CPU is worthwhile. Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Mar 12 21:32:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BDB1A08BA for ; Wed, 12 Mar 2014 21:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byE4weXF8IuK for ; Wed, 12 Mar 2014 21:32:07 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (agjbgdcfdbfi.dreamhost.com [69.163.253.158]) by ietfa.amsl.com (Postfix) with ESMTP id 32A2F1A08B8 for ; Wed, 12 Mar 2014 21:32:07 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 54B471B405F for ; Wed, 12 Mar 2014 21:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=Rk7NiDo6Xu4adFDzV6mdtv8zjDY=; b=xzyljdhjKII 4CRhSrGXEauXZ7OUDqw8P0dSvm0KCJI8aX9LBNgkfNkanEPMg1LGTlCWtyiUMtEj 2euAmZOo+vDb4TybpoAX82++7CAxNR7FbGi08A+ARkOrYbSqVcSq2Ytz9DqhAttR rfxvODUuZMQY5y8Ykp8crRQF8WWHTOuA= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 07B021B4059 for ; Wed, 12 Mar 2014 21:31:59 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hm4so3039780wib.4 for ; Wed, 12 Mar 2014 21:31:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=gTX1Xog8mWXG2J2azGuHvAMiIb4pHBDcB5Df7mm/Sg8=; b=A+DpPeaGh7kiF2gY+I1QBbieuCSbfxJuKgeN0OE7vzd6/caEp4hHAYL276E2FUKqRK mz6WOQAGrrTAAae2YjJFaxLqAi2VvQ51i4djib56KYVz1qaruazfyOKoKOpXGLze/9Z3 f07Em7ldfqnLIjGeU/Pndx9Ltb+PtHQ2dJi7R8agf0YyMlS5vm2GV2XBgCs9iQMdu5ns 9RkpsrePv5gMAuXddc7BlPQob3+ojNmr0i9h8m0fQpfxN83L01kZJ8ekij73+oBPA96b Mu6SqAA/3u7puS0SAND4S26aH7q+z9wb7VQXro9IC5UXREmfMkighsFXplSvZ6jQlJR4 SctA== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr10525214wib.39.1394685118677; Wed, 12 Mar 2014 21:31:58 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 21:31:58 -0700 (PDT) Date: Wed, 12 Mar 2014 23:31:58 -0500 Message-ID: From: Nico Williams To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/h1yYw1JfgwC86xFRO2cAqIGGQYA Subject: [TLS] I-D for ECDH anon AES AEAD ciphersuite registration (Fwd: New Version Notification ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 04:32:08 -0000 See below. (And just now, after crossing every reference t and dotting every i, I realized I did not say explicitly that these are for ephemeral ECDH public keys. Sure, it's strongly implied, but still...) Please review. ---------- Forwarded message ---------- From: Date: Wed, Mar 12, 2014 at 11:27 PM Subject: New Version Notification for draft-williams-tls-anon-ecdh-modern-cipher-00.txt To: Nicolas Williams A new version of I-D, draft-williams-tls-anon-ecdh-modern-cipher-00.txt has been successfully submitted by Nicolas Williams and posted to the IETF repository. Name: draft-williams-tls-anon-ecdh-modern-cipher Revision: 00 Title: Anonymous ECDH Ciphersuites with Modern Ciphers and Cipher Modes for Transport Layer Security (TLS) Document date: 2014-03-12 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-williams-tls-anon-ecdh-modern-cipher-00.txt Status: https://datatracker.ietf.org/doc/draft-williams-tls-anon-ecdh-modern-cipher/ Htmlized: http://tools.ietf.org/html/draft-williams-tls-anon-ecdh-modern-cipher-00 Abstract: This document requests the registration and allocation of codepoints for new Transport Layer Security (TLS) ciphersuites with modern ciphers and cipher modes. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Mar 12 21:50:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823461A04F6 for ; Wed, 12 Mar 2014 21:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPmAUoQCDYN1 for ; Wed, 12 Mar 2014 21:50:40 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id AFBCB1A08B0 for ; Wed, 12 Mar 2014 21:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1394686234; x=1426222234; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=owoYs8ei3+NbfPwW2cvvTurR//k8a/Lpd7GKzYy6v4A=; b=CD1atLdZSQ+mk8WQfVs2zUwrMPMwm9dNBgxlZnlVl9RZn9ODh/Pwv/00 iwqJWzMEJHRZzdUieqR6a8CzK0VShTg5QJDXBkvXZwQBmkq+4VBR4JbfE +Mh5a1EG26FSSrU1brP2RXVHd7EFR23HbTxcQk1muEf1Rf5wjviyo0fSd Y=; X-IronPort-AV: E=Sophos;i="4.97,644,1389697200"; d="scan'208";a="239369142" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 13 Mar 2014 17:50:32 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Thu, 13 Mar 2014 17:50:32 +1300 From: Peter Gutmann To: "ietf-ssh@netbsd.org" , "" Thread-Topic: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx Thread-Index: Ac8+d8OhohuCIUnlQ2Op/mVzyohdOQ== Date: Thu, 13 Mar 2014 04:50:32 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C737238AD92@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eVWatEXDD5rHKzDuzfezaX-fvek Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 04:50:45 -0000 Daniel Kahn Gillmor writes:=0A= =0A= >0) either the software or the admin must manually provision the certificat= e=0A= >for the server; this means making decisions about questions that don't=0A= >necessarily have any good answers, which is not a situation you want your= =0A= >users to be in. Servers operating in a pool now need to have some sort of= =0A= >secret key distribution mechanism, for example.=0A= =0A= One option for this is for the server to auto-generate the cert on first=0A= install/setup. The alternative that's currently used on way too many devic= es=0A= is for them to have a pre-generated generic cert with incorrect ID informat= ion=0A= with the private key shared across all devices.=0A= =0A= Peter.= From nobody Wed Mar 12 21:55:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF8E1A04F6 for ; Wed, 12 Mar 2014 21:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.1 X-Spam-Level: *** X-Spam-Status: No, score=3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347, RDNS_NONE=0.793] 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 NV9glr7lLpWD for ; Wed, 12 Mar 2014 21:55:06 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (unknown [69.163.253.167]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBF61A03A5 for ; Wed, 12 Mar 2014 21:55:06 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 48E1120024943 for ; Wed, 12 Mar 2014 21:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=n3JCZIxjMRfGYkhlDiiL FVzLGwc=; b=evU6MyGPV8DDpewcHfFb1S+/aEx4CHCLPyS5RFlnu/YEtmt1PIlx 3ywsoFEYAUuW+VTJlujA+1BHYhra37N/BCBDu//iBTBcMRrjuWUmOmiP0jtQ+Y1j ZRs24IdIDGz0b6QNyIaPU/ZSNXo/AeBO0Y0qMAEpMRJgAPg5DDOhsY0= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id ECD1520024941 for ; Wed, 12 Mar 2014 21:54:59 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hm4so3052280wib.0 for ; Wed, 12 Mar 2014 21:54:58 -0700 (PDT) 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=3ZjfmdY6o9nW6kVLmkbD5A2toisnhcBrbXOz7tn/GDk=; b=Kj3ullGAKPppmtF9an73Ft3u10rUPoF0DNOCWQfPp94hJJJjrpxOevORJEezOmB8iN vDlM8NNSEK4w8BIeBxU4mcUuZeNF9dBMBHELaPPVm7o4WSjJwZFPpQxD/+oxxb0p/DFo JesBeFBxWL1CJ4YiNIHBUHQW7CqY8z0KeBwji2qw9qyjcVRTpPAwr0v48pI8EpSt4ktx ayRQUllnMDI+0/KGSkIeDFkd+VPjBwsJhBvyOuzTQJiWjCJufHsVUo9HEgOWHz2PD/W5 rcsE+danLL9Yzu/9pPFDFiHyp5K1pQkICFrJY4Oy8edCWNNYN7/WwmnbTZdUfFOqZwcV IQYA== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr10481272wib.5.1394686498848; Wed, 12 Mar 2014 21:54:58 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 21:54:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Mar 2014 23:54:58 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/E0noz0l9cUBgfq11NtXCXzEBXc0 Cc: "tls@ietf.org" Subject: Re: [TLS] Thoughts on TLS 1.3 cryptography performance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 04:55:07 -0000 Isn't session resumption with session tickets faster still and -provided the insufficiency of binding from resumed to original session is fixed- as secure? Ah, you want PFS even on resumption, but surely that could be added, and even then the result should still perform even better than your proposal. Nico -- From nobody Wed Mar 12 22:02:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473FC1A0800 for ; Wed, 12 Mar 2014 22:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.744 X-Spam-Level: X-Spam-Status: No, score=-0.744 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] 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 qnXW9bZValhC for ; Wed, 12 Mar 2014 22:02:26 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (agjbgdcfdbfc.dreamhost.com [69.163.253.152]) by ietfa.amsl.com (Postfix) with ESMTP id 6A69D1A03A5 for ; Wed, 12 Mar 2014 22:02:26 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id D975A2005D109 for ; Wed, 12 Mar 2014 22:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=miRupZy/kKWFL1hk1f1Skfcsprw=; b=oZi+wMRtDHB 7STm5BqjeWViN6v2YxX36AjGcC/IKDN/NZAMifYR5k6/J3WmrQQw/4MF7s//dtgO kl757I2NW6Qa7DRVSiDhtEYyRtFyNjuP+EC05mb79evINnkuDFgOY6i7xYoR0jlW bhUscfdQAlFUCJD8Iv95l1MdC6pqIx0s= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id 8A46D2005D107 for ; Wed, 12 Mar 2014 22:02:19 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a1so384111wgh.32 for ; Wed, 12 Mar 2014 22:02:18 -0700 (PDT) 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:content-transfer-encoding; bh=4glntL2q8fFbX1BE819E/5fIhX+Qz+jGubVGssIUx6Q=; b=Z2Ia2EPhQ/IDgqIgnEP4hnCjmDL6V/IF7cpIFSjlgARlhFPobb1xlWBXqLZobPjgFO zqe1nYyIvqAbWUNnikMZOjjBWGS/+hWUOy+piACuET2voEf0JVqo8amEgAdc9MG2+OcQ iNx55OR4QiYz1bdOPI7aBbWomw/aQpuB0+3rYtKWMjeAeYpI8o5fvenowOaylczo+Y1I 1jVe7CeZYOUEF0WUVhqmSXAHE48CupYqiK/KwSPzCIbLVslIIfersRWG195oRk2XLL1E GTh/chkrMsfbBh/sarQKlCobsP5M/OSREJ7Uv2ttt7S9siXTvhKZlRBCPlg1M7bcn92C uORw== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr10599435wib.39.1394686938393; Wed, 12 Mar 2014 22:02:18 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 22:02:18 -0700 (PDT) In-Reply-To: <532024EF.4060607@polarssl.org> References: <532024EF.4060607@polarssl.org> Date: Thu, 13 Mar 2014 00:02:18 -0500 Message-ID: From: Nico Williams To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/S6wb5wD72qR0V4FcuHLDcgo_GdU Cc: "tls@ietf.org" Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 05:02:27 -0000 On Wed, Mar 12, 2014 at 4:12 AM, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > On 03/11/2014 11:49 PM, Nico Williams wrote: >> This is a big problem for anything that wants to do opportunistic TLS >> (e.g., MTAs, like Postfix). >> > Sorry if I'm missing something obvious, but why would ECDH_anon be a requ= irement > for opportunistic TLS? Can't we just use certificates and not validate th= em? > > Or are you rather interested in the performance gain of ECDH_anon over > authenticated and forward-secure key exchanges? Just because a client and server negotiated an anon ciphersuite does NOT mean that they won't authenticate each other. For example: - the client might initiate renegotiation to send an SNI and get an appropriate server certificate, - or the client might use application-layer authentication with channel binding. Or maybe not authenticating each other is fine and then -yes- ECDH performance will be appealing. In the SMTP case when there's no TLSA RRs in the DNS for the server and the server has no certificates, the client may prefer to use anon DH/ECDH. Considering that e-mail has historically had very poor privacy protection, that would be a huge step up. But today an SMTP client can't get high-performance ECDH and AEAD ciphers :( Nico -- From nobody Wed Mar 12 23:12:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53ECB1A08D7 for ; Wed, 12 Mar 2014 23:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe3_kmraw5NI for ; Wed, 12 Mar 2014 23:12:19 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 656C01A08D6 for ; Wed, 12 Mar 2014 23:12:19 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id v1so575314yhn.28 for ; Wed, 12 Mar 2014 23:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Zwyd03anNRXHmtuKOC/sziCHrY4PP8dfG31vNNUZ5hU=; b=tnQbCXLmSDty2fr2OcPrNRbgSdbI9rmpJHgCexZ0PVs/nj/UKPvf7O+4AbQR0ZjQAs Eo2labzM+Y3pSbgDNu2JeEwQYzS3kzPKdw4N3UkjGDVwrPU25m2OSTRmOQkrDLAYoH6N 1ENvgGpKKhCFatrrkWZ3SQ0BLjFkmYLkk+r+hOJTe//bEYC+i9SZU4SjPKeDyq2x+HJF 3GSd5Bk/ZqSg4EF7WwfkuWnrKzGlD/0ZsZCo18Si82fOAV/T2dPSY2Cr83EECWi2YLPY Q44rERKxM/s1gYiYwk17BG/WcFjb+hG8zvqCmYD1jnCfmp8oIU4c4EolELXTjk5F+bZw 8CDA== MIME-Version: 1.0 X-Received: by 10.236.90.12 with SMTP id d12mr92571yhf.120.1394691132985; Wed, 12 Mar 2014 23:12:12 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Wed, 12 Mar 2014 23:12:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Mar 2014 23:12:12 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hKLms7oG_BgJY1NvO1QsyAV6lMA Cc: "tls@ietf.org" Subject: Re: [TLS] Thoughts on TLS 1.3 cryptography performance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 06:12:21 -0000 On Wed, Mar 12, 2014 at 9:54 PM, Nico Williams wrote: > Isn't session resumption with session tickets faster still and > -provided the insufficiency of binding from resumed to original > session is fixed- as secure? Ah, you want PFS even on resumption, but > surely that could be added, and even then the result should still > perform even better than your proposal. The performance gain doesn't work like that. It's not from the client having seen the g^a before, but that the server doesn't need to sign a new value every time it does a handshake. The client can avoid validations if it can remember a global database of public information, but if not it is only slightly worse off then today in calculation. By contrast resumption only works if the client maintains some data that has to be kept secret, and if the server still remembers how to read the tickets that it handed out. Having resumption doesn't stop servers going to ECDHE and ECDSA for efficiency reasons. Particularly at higher security, RSA is extremely slow: my computer can only do 111 RSA 4096 signatures a second. It can do 24 times as many P521 signatures. Even if a small minority of all connections require a public key operation, that difference matters. (Signatures are equivalent to decryption, in case people were wondering about RSA handshakes sans PFS) Adding PFS to resumption requires two exponentiations client and server side: one fixed base, one variable base. At that point we've done enough work to completely redo the connection with HMQV. (well, modulo the client regenerating its key periodically, or maybe once per connection for anonymity, and I've ignored the fact that in genus 2 or on Kummer varieties you have a problem with HMQV and have to do triple DH instead) I don't see anyone paying that penalty anytime soon. But don't take my word for it: from Cloudflare: "Because ECDSA is so much more efficient for our servers, supporting these certificates is an essential step for enabling SSL for free in 2014." CPU matters. Sincerely, Watson Ladd > > Nico > -- -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Mar 12 23:27:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940621A08FF for ; Wed, 12 Mar 2014 23:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8M9fHk9iTvQZ for ; Wed, 12 Mar 2014 23:27:05 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (agjbgdcfdbed.dreamhost.com [69.163.253.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0721A08DF for ; Wed, 12 Mar 2014 23:27:05 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 550DB2005D107 for ; Wed, 12 Mar 2014 23:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ahnjw27iflRJpnzw9bmF uJaXuYQ=; b=e0k6adPyihP4N61YcXC6wKeEVq+f0syiFVo1wWJKq6ms4GuADaj8 4ifMkbz1++1DYmaPRQ2LkUOGEei+eeHVWEr4rnFGd15mdu2ngh0Frl5Xbp+cJUMI 83ABAvVx/dpblLrUP3ssRiQNRe0Ny3vppmn9HBHqO+By93y9+Ap9SSI= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id 074552005D106 for ; Wed, 12 Mar 2014 23:26:58 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hm4so632448wib.1 for ; Wed, 12 Mar 2014 23:26:57 -0700 (PDT) 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=Cb9w0LUoyBgZ56arRnwMcxDsLDAgSYgfGArIR8wowyE=; b=k7qirkrwnspceBZh9ZGNPyShYdmeszeVzA92TUenhXHODxPQ5ZwKWkE9wdPMbDDD1b Udq7PFzDMshP/goiJ4t8ZnDkShrYgZm9hjmV2Emc9TqCWgH8hC62A3pLbWdBq/znudpX glmZjb3/nLPuEDogJ0+Rmuqku0vyfelvMhPWji+h4cSMWVMMXT+Lo0pteFnGJQSUG65u e4CiRLuHg2LQfuaC4WA1ILvtF/Oz5qES52YAagnoFuFXhviaVcNDTZih69ZLLMrNjQoH QLmV14nFaIPodrZIKwOSh0pO8RfTmSTpQGPRSXi8grDMfvcSHKXZGAxGQZadrgqv/PT5 CAvQ== MIME-Version: 1.0 X-Received: by 10.180.77.74 with SMTP id q10mr40664wiw.39.1394692017710; Wed, 12 Mar 2014 23:26:57 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 23:26:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Mar 2014 01:26:57 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fxtZ_flRkK_0NRFV1udQQHNH4vE Cc: "tls@ietf.org" Subject: Re: [TLS] Thoughts on TLS 1.3 cryptography performance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 06:27:06 -0000 On Thu, Mar 13, 2014 at 1:12 AM, Watson Ladd wrote: > On Wed, Mar 12, 2014 at 9:54 PM, Nico Williams wrote: >> Isn't session resumption with session tickets faster still and >> -provided the insufficiency of binding from resumed to original >> session is fixed- as secure? Ah, you want PFS even on resumption, but >> surely that could be added, and even then the result should still >> perform even better than your proposal. > > The performance gain doesn't work like that. It's not from the client > having seen the g^a before, but that the server doesn't need to sign a > new value every time it does a handshake. The client can avoid > validations if it can remember a global database of public > information, but if not it is only slightly worse off then today in > calculation. Well, but with resumption the signature validation is also optimized away for a while. > By contrast resumption only works if the client maintains some data > that has to be kept secret, and if the server still remembers how to > read the tickets that it handed out. [...] Ah! Thanks, that's the key. It's OK to expect servers to remember how to read their session tickets. As for the need to keep session resumption tickets private on the client side... certainly the client would have to provide integrity protection to any cache of signature validations and server public ECDH keys, but ticket compromise is rather severe: past non-PFS resumptions are compromised and the attacker can impersonate the client in future resumptions regardless of past PFS use. Of course, in your scheme if the client can't protect its local cache then it's subject to some MITM attacks, but that's a much smaller concern. Thanks, Nico -- From nobody Thu Mar 13 00:27:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD301A08F3 for ; Thu, 13 Mar 2014 00:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] 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 SXEfiDn0aMqb for ; Thu, 13 Mar 2014 00:27:55 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (unknown [69.163.253.175]) by ietfa.amsl.com (Postfix) with ESMTP id AC9BC1A0155 for ; Thu, 13 Mar 2014 00:27:55 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id CC6FA428076 for ; Thu, 13 Mar 2014 00:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=gWdgau/kxYuDy6n/CC6TOTf vGF4=; b=x2fgQoAkb0XJ15vKeISyeYgmfgig5ow54Au3DirJngAOrbamRv9/IGv m7uq3s/XSUZRj6sm9XYcJ5OLEHVcOrfgP7zXNt42W2Dp4cfsjNozJpQ3MgXCfrAI uKC7QS1pt+ACPg77//xdr5fJE3axSTCFG5F96QgnsaZQOgjZzNoY= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 7F6E3428075 for ; Thu, 13 Mar 2014 00:27:48 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hm4so3151357wib.2 for ; Thu, 13 Mar 2014 00:27:46 -0700 (PDT) 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=uRKi+xTZt4ZyxJUpxkftho1UlRvOoX+nmj4yFtbnhsY=; b=V5Ax7rahzPHNqwQDp3Z9sSfpdwnvOFBedASq8XVW4vxxyhdEdkgfmML0Lfb7PAvRxf xPQjdchWAYNT32CVn3jXF3ZwxzYU9YRejZVM5QjxxhcMaKN7H28HDALJFwpre9hTSQn3 Ysp59hsRwSJHfCYrxfsDC9hYonFdIFGFPoDa3mQ7mrIdQ91ZjnxFbdYha/6pt6XzF/zP Z3KGW14NvzjcdEYDS9cF6ejsctH4OdD2gpTtjCGvZlSPXhj5SQYhBGP4Y7AwhybxTdyO yHyXy/xy+4rPB28h5Poa2u7Pb0pwF1zJXhG+rJvIvfpYigWgkO/28S7krpZwZtrEqKnv YBOw== MIME-Version: 1.0 X-Received: by 10.180.97.72 with SMTP id dy8mr268820wib.5.1394695666124; Thu, 13 Mar 2014 00:27:46 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Thu, 13 Mar 2014 00:27:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Mar 2014 02:27:46 -0500 Message-ID: From: Nico Williams To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/isqD64Wn3hk6JQ4i2KjgyliR22s Subject: Re: [TLS] I-D for ECDH anon AES AEAD ciphersuite registration (Fwd: New Version Notification ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 07:27:56 -0000 On Wed, Mar 12, 2014 at 11:31 PM, Nico Williams wrote: > (And just now, after crossing every reference t and dotting every i, I > realized I did not say explicitly that these are for ephemeral ECDH > public keys. Sure, it's strongly implied, but still...) Argh, I also forgot to add AES-256. Bah. Tomorrow I'll submit a -01. From nobody Thu Mar 13 01:01:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2711A094E for ; Thu, 13 Mar 2014 01:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-OJELiiXMMb for ; Thu, 13 Mar 2014 01:01:38 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6621B1A0963 for ; Thu, 13 Mar 2014 01:01:38 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so699986wiw.17 for ; Thu, 13 Mar 2014 01:01:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rP8XoUiFrcOGYmhIPsEWlWgez4kfpAZ2VPRRwlXDNhE=; b=EwlUehBRXR6qrGAeA5tHWVJY/luEORyZZJCULn7L1PWgDRjHzid2r6j0OSF+xEuijU TYxyhZcIcugd1XFByqysSc/qzmV6C9zRvmZUjjvpsojVxXFOBfe/KX+IUy1/zB2sUddZ M12gwXTP+NY7vSfL8RUScztxZv3qDue6RdHHeufQkIgJeGLSRi6xVkh6klws5E1LUSzq yzxKnTk6bCawAohkqJQ61P+qTSXT7jhRtj13f+epMEsHlg1aQlbbjoyBkwVi04zE4hKc PceVIzhvxpDKW6X4w8rWAB8Feu6u0E3s8lW7kFZKEOjqgcEK9gvg1kTc4fb1BnT+sRPp +J2w== X-Gm-Message-State: ALoCoQk38FH6O39Fw8lRj2/sJUYKfGmFHoP+3gRDdMzLwOKkt35cdGSsiOYuk3IB72CPLUtjMvtm MIME-Version: 1.0 X-Received: by 10.180.19.35 with SMTP id b3mr445231wie.20.1394697691560; Thu, 13 Mar 2014 01:01:31 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Thu, 13 Mar 2014 01:01:31 -0700 (PDT) X-Originating-IP: [184.23.29.222] In-Reply-To: References: Date: Thu, 13 Mar 2014 01:01:31 -0700 Message-ID: From: Trevor Perrin To: Nico Williams Content-Type: multipart/alternative; boundary=bcaec53d5eb57996a404f4785cf2 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tbyJQTmehcf9tUDwHjBS8VNdBdw Cc: "tls@ietf.org" Subject: Re: [TLS] Thoughts on TLS 1.3 cryptography performance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 08:01:40 -0000 --bcaec53d5eb57996a404f4785cf2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 12, 2014 at 11:26 PM, Nico Williams wrote: > On Thu, Mar 13, 2014 at 1:12 AM, Watson Ladd > wrote: > > On Wed, Mar 12, 2014 at 9:54 PM, Nico Williams > wrote: > > > By contrast resumption only works if the client maintains some data > > that has to be kept secret, and if the server still remembers how to > > read the tickets that it handed out. [...] > > Ah! Thanks, that's the key. It's OK to expect servers to remember > how to read their session tickets. As for the need to keep session > resumption tickets private on the client side... certainly the client > would have to provide integrity protection to any cache of signature > validations and server public ECDH keys, but ticket compromise is > rather severe: past non-PFS resumptions are compromised Not necessarily. The cached session key doesn't need to be the same as the session key for previous sessions. And 0-RTT resumptions could have a DH exchange overlaid on the 1st RT, so they get PFS after that RT. > and the > attacker can impersonate the client in future resumptions regardless > of past PFS use. And impersonate the server to the client. > Of course, in your scheme if the client can't > protect its local cache then it's subject to some MITM attacks, but > that's a much smaller concern. > On the other side of the balance - doing 0-RTT resumption based on session tickets saves at least 1 DH compared to the 0-RTT flow in EKR's draft or QUIC. If clients need to re-authenticate with something like ChannelID, it might save a second asymmetric op. Seems worth considering. Trevor --bcaec53d5eb57996a404f4785cf2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Wed, Mar 12, 2014 at 11:26 PM, Nico Williams <nico@cryptonector.com= > wrote:
On Thu, Mar 13, 2014 at 1:12 AM, Watson Ladd <watsonbladd@gmail.co= m> wrote:
> On Wed, Mar 12, 2014 at 9:54 PM, Nico Williams <nico@cryptonector.com> wrote= :

> By contrast resumption only works if the client maintains some data > that has to be kept secret, and if the server still remembers how to
> read the tickets that it handed out. =A0[...]

Ah! =A0Thanks, that's the key. =A0It's OK to expect servers to reme= mber
how to read their session tickets. =A0As for the need to keep session
resumption tickets private on the client side... certainly the client
would have to provide integrity protection to any cache of signature
validations and server public ECDH keys, but ticket compromise is
rather severe: past non-PFS resumptions are compromised
Not necessarily. =A0The cached session key doesn't ne= ed to be the same as the session key for previous sessions. =A0And 0-RTT re= sumptions could have a DH exchange overlaid on the 1st RT, so they get PFS = after that RT.

=A0
and the
attacker can impersonate the client in future resumptions regardless
of past PFS use.

And impersonate the s= erver to the client.

=A0
=A0Of course, in your scheme if the client can't
protect its local cache then it's subject to some MITM attacks, but
that's a much smaller concern.

On the other side of the balance - doing 0-RTT resumption based on session= tickets saves at least 1 DH compared to the 0-RTT flow in EKR's draft = or QUIC. =A0If clients need to re-authenticate with something like ChannelI= D, it might save a second asymmetric op. =A0Seems worth considering.


Trevor

<= /div>
--bcaec53d5eb57996a404f4785cf2-- From nobody Thu Mar 13 06:22:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100A11A092A for ; Thu, 13 Mar 2014 06:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRPTqV9_z4f4 for ; Thu, 13 Mar 2014 06:22:27 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 14F941A08B8 for ; Thu, 13 Mar 2014 06:22:26 -0700 (PDT) Received: from [10.93.112.86] (94.197.120.97.threembb.co.uk [94.197.120.97]) by entima.net (Postfix) with ESMTPSA id 7820A601CC; Thu, 13 Mar 2014 13:22:19 +0000 (GMT) User-Agent: K-9 Mail for Android In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C737238AD92@uxcn10-6.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C737238AD92@uxcn10-6.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Thu, 13 Mar 2014 13:22:14 +0000 To: Peter Gutmann , "ietf-ssh@netbsd.org" , "" Message-ID: <826e1c57-6d87-47e7-a064-347992fd5606@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1nB18i6jigF8ndbZNT0vr7EuLPQ Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 13:22:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 13 March 2014 04:50:32 GMT+00:00, Peter Gutmann wrote: >The alternative that's currently used on way too many >devices >is for them to have a pre-generated generic cert with incorrect ID >information >with the private key shared across all devices. Can we perhaps make that a SHOULD NOT (or even a MUST NOT), if it somehow isn't already? It's way too common in the wild, and it really is next to useless practice from the same kind of wilful carelessness that brought the world so many default/engineering/field service passwords/backdoors. The related, but more unwitting, case of devices (often embedded) with bad RNGs which don't collect enough entropy on warmup generating keys on startup which turn out to be one of a globally limited set of practically-enumerable keys is also one for implementers and testers to watch out for, and is also actively seen and exploited in the wild: I think we should have strong advice about that as it's a depressingly common pitfall. - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.0.9 iQI3BAEBCgAhBQJTIbEGGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6QosP/i0xem6cxWoaPbO0OWmsKa05Y9VudKvl8nBW8+xLxNo6SPq1rLaI +y+A/PpYHWBDKUoQHp0KRr23mAcjq175zYSKE4DBciRSjmZ/HGgedoElKYcvF8mr erB8ruUKqdeFn5Y0niUTdyu7I0btxsjnGEkiqjxUp3Nvj+6Z66dQ45hNU86QUP5h P8TgHfY1KlOU20FnVnHgiZD97upaBG9uWTwVYnw6mQFu/AEXwASR6U0BT0VrF+j6 wHKPxZhKHa5IhPwRIka0CDXGKLFdxDdF0uLUQ6leEazznWx164itBRwWJOKr3FB4 xQEqtMVJeQen+nAYQwA4qHsKoG/p+s13SKCWcYiLd6FDzasRY215b0ArtmrDi5Kh nPu6WeZaadi6bLw31b8KXChennTYe+B+1mLatjAyFVeQ5hZI3dcXkZlX1gB35KrO Q6zIsoVRQqovmyfuhIOg7XDUc7FENWyCyCRBEPNI7Vzyw24oMNA6lmBBodbAPg9Q 9IqiVEjXdvreWT6f7ppy5Ns3F+2Vb/RLPhyl79u3NgfRIDQVZYz7DTqLmsTADubs LJop+2iVMDUD6o+14GKqmYgw/Sf/t2uWBsiIEib2LPZ5ebeso0BldcsCmTt0Fbja CmPGgWgKIjfQzJlA9ijq5rC0+xji9iYDg2d1+uSGdRX2RbPr0qmgmUcP =/9kY -----END PGP SIGNATURE----- From nobody Thu Mar 13 09:34:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C5C1A0A33 for ; Thu, 13 Mar 2014 09:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qANBxamWZt7l for ; Thu, 13 Mar 2014 09:34:50 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (agjbgdcfdbfg.dreamhost.com [69.163.253.156]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE8B1A0A2D for ; Thu, 13 Mar 2014 09:34:50 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id D9C7FB8058 for ; Thu, 13 Mar 2014 09:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=uuNGm/aNkx6WuovuF8zt xHWUaeU=; b=WkmYDPBOaqM7EfPv/bjvQYIlN/gvWTDawHojV5J+OR3Plk0getfW /Yk2KVITMrfrYJ0ZzHYiO7LoNxDX5gJiVC/LXLVJz8oLZ7oZp3J56cEKi/s4KD5u 2r0caSVqpitB0p8vLSdWEeJS98SkvbW5FAHa8fZnTIgZ1U/c/+a41L8= Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 88D05B806D for ; Thu, 13 Mar 2014 09:34:43 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id cc10so4184661wib.2 for ; Thu, 13 Mar 2014 09:34:42 -0700 (PDT) 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=5SRtpP2MuDBNFyWdQpANtdIxU7sFkoin6kvXK9Ygvcw=; b=N3UfeGknCkduBzdcqplH5JeJR1pCenLzg7XqQVhaQIho1oTrB2unktAp2OPHLG2/32 ad5YSXThPkZRJOzVLNp/nsr9/s6dpZ2atKIuXfROi+EiMauiDEt9k+Wp3CDUrVFvHLdC 1FVC0gH3EeMT68WA0QUZuE8x/tlfjfUQmZCRmPLFthOGbioCV18/0UATfAjfRKn+v/q/ /88dIYPuJ66WXfjiHrtNgkpqC7+3EceqzA24Xj1DVIPGJprm5d1YBVza0spo7IAe1TpA qiAl4jWYFwPvq7GLN4PnZ7+MhaiZTShJCcktjCKeGdritqf6K7fjFChdtXftrqbTsA7/ ksDw== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr2339005wib.39.1394728482248; Thu, 13 Mar 2014 09:34:42 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Thu, 13 Mar 2014 09:34:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Mar 2014 11:34:42 -0500 Message-ID: From: Nico Williams To: Trevor Perrin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3tTzoXcxiP5q1MU_YUUs3oFrP_w Cc: "tls@ietf.org" Subject: Re: [TLS] Thoughts on TLS 1.3 cryptography performance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 16:34:52 -0000 On Thu, Mar 13, 2014 at 3:01 AM, Trevor Perrin wrote: > On Wed, Mar 12, 2014 at 11:26 PM, Nico Williams > wrote: >> On Thu, Mar 13, 2014 at 1:12 AM, Watson Ladd >> wrote: >> > By contrast resumption only works if the client maintains some data >> > that has to be kept secret, and if the server still remembers how to >> > read the tickets that it handed out. [...] >> >> Ah! Thanks, that's the key. It's OK to expect servers to remember >> how to read their session tickets. As for the need to keep session >> resumption tickets private on the client side... certainly the client >> would have to provide integrity protection to any cache of signature >> validations and server public ECDH keys, but ticket compromise is >> rather severe: past non-PFS resumptions are compromised > > Not necessarily. The cached session key doesn't need to be the same as the > session key for previous sessions. And 0-RTT resumptions could have a DH > exchange overlaid on the 1st RT, so they get PFS after that RT. I didn't say previous sessions are compromised, I said "past non-PFS resumptions are compromised", since they were non-PFS and the session resumption ticket used to resumed them is compromised, it follows that those past resumptions are compromised. >> and the >> attacker can impersonate the client in future resumptions regardless >> of past PFS use. > > And impersonate the server to the client. Yes. >> Of course, in your scheme if the client can't >> protect its local cache then it's subject to some MITM attacks, but >> that's a much smaller concern. > > On the other side of the balance - doing 0-RTT resumption based on session > tickets saves at least 1 DH compared to the 0-RTT flow in EKR's draft or > QUIC. If clients need to re-authenticate with something like ChannelID, it > might save a second asymmetric op. Seems worth considering. I don't think anyone has made an argument against session resumption in this thread. Watson's proposal is one that reduces asymmetric crypto load in a way that reminds me of resumption, but isn't, and in particular in a way that is less brittle on the client side w.r.t. confidentiality protection of local secrets. Now, the client is bound to have to provide confidentiality protection for local secrets in *all* cases, but in Watson's scheme generally only of long-term keys or current session keys). So I'm not really too concerned about the client's need to keep resumption tickets secret: it can always store the resumption keys encrypted in another secret, so as to minimize the number of secrets to store in a secure element/token/whatever. But I am concerned about the need for PFS on resumption in order to limit the extent of resumption ticket cache compromise; if you're going to lose the 0-RTT resumption for it, might as well pick the best "fast reauthentication" protocol possible, and that might be Watson's. Nico -- From nobody Thu Mar 13 09:49:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F3D1A0A23 for ; Thu, 13 Mar 2014 09:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amoagUUhCXEa for ; Thu, 13 Mar 2014 09:49:08 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id 039721A0873 for ; Thu, 13 Mar 2014 09:49:07 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so1087456wes.4 for ; Thu, 13 Mar 2014 09:49:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lNlmI9UB6YK4Cxm4GZfYLCRFxgCWwDG4CwF1GEGP3eU=; b=XuwRo2zfm4A8O9jitDqzh4jVZC8LsLurxcwJiq1GJ5L8KayTCU6w0Pzvc/vQ9Lod32 Etj5bol3WsJ/uTFOQ2/AftjQjPxg5xjfDPPFSzNVGgtcXt5FYYpU6bSVclrFAlnj/bRB AoLRnOuXHuskUSqecBIQEQJ6UQ0p7cxqqIicYd6F4RcrKdGKiaCqeA2lGWPzuxXrV7Di GTbUtRezNymeskswF8NzqWDnadOy4HTv8xqRrgWc288W/t+P6VbJMrks3OnATpy+RdMc tm4Mnd5eR3ktgvOREsr0psQ0bgOkqwYHuAAeOix9U9MGOgaa6RVTyG30QKkauMhbxUvp AUfg== X-Gm-Message-State: ALoCoQmUYZgoCQ2nLqDYLrUvD3uyReRZINqw7rIMX9VQJlVlzE4XzaUCrhL/zdR+AZzliFm3D8je X-Received: by 10.180.101.40 with SMTP id fd8mr2426405wib.1.1394729341042; Thu, 13 Mar 2014 09:49:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Thu, 13 Mar 2014 09:48:20 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Thu, 13 Mar 2014 09:48:20 -0700 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=f46d041826c6eee34604f47fbae3 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mW2xq3xKMnRqzbLNyv9-r-Om2EU Cc: "tls@ietf.org" Subject: Re: [TLS] Thoughts on TLS 1.3 cryptography performance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 16:49:10 -0000 --f46d041826c6eee34604f47fbae3 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 13, 2014 at 9:34 AM, Nico Williams wrote: > But I am concerned about the need for PFS on > resumption in order to limit the extent of resumption ticket cache > compromise; if you're going to lose the 0-RTT resumption for it, might > as well pick the best "fast reauthentication" protocol possible, and > that might be Watson's. WRT this specific point, I wanted to observe that computational cost (within reason) is less important than round trip delay, for a number of reasons: - We already have a mechanism for radically reducing the cryptographic cost by replacing RSA certificates with EC certificates, so we're going to get a large speedup without changing the pattern of crypto operations much at all. - It's possible to ameliorate computational cost by throwing money at the problem in terms of more CPU, but it's much harder to unilaterally do much about round-trip delay. - Computers are still getting faster and cheaper, but the speed of light is unlikely to change. I'm certainly not suggesting that we shouldn't minimize the number of cryptographic operations where practical, but generally I think it's more important to minimize the number of round trips. -Ekr --f46d041826c6eee34604f47fbae3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 13, 2014 at 9:34 AM, Nico Williams <nico@cryptonector.com&= gt; wrote:
=A0But I am concerned about the need fo= r PFS on
resumption in order to limit the extent of resumption ticket cache
compromise; if you're going to lose the 0-RTT resumption for it, might<= br> as well pick the best "fast reauthentication" protocol possible, = and
that might be Watson's.

WRT this specif= ic point, I wanted to observe that computational cost
(within rea= son) is less important than round trip delay, for a number of
reasons:

- We already have a mechanism for radical= ly reducing the cryptographic
=A0 cost by replacing RSA certi= ficates with EC certificates, so we're going
=A0 to get a large speedup without changing the pattern of crypto operation= s
=A0 much at all.
=A0
- It's possible to= ameliorate computational cost by throwing money at the
=A0 probl= em in terms of more CPU, but it's much harder to unilaterally
=A0 do much about round-trip delay.

- Compute= rs are still getting faster and cheaper, but the speed of light
= =A0 is unlikely to change.

I'm certainly not s= uggesting that we shouldn't minimize the number of
cryptographic operations where practical, but generally I think it'= ;s more
important to minimize the number of round trips.

-Ekr

--f46d041826c6eee34604f47fbae3-- From nobody Thu Mar 13 09:52:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D871A0A40 for ; Thu, 13 Mar 2014 09:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlG3Ke3uXUPz for ; Thu, 13 Mar 2014 09:52:58 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (agjbgdcfdbeb.dreamhost.com [69.163.253.141]) by ietfa.amsl.com (Postfix) with ESMTP id 10C821A09CE for ; Thu, 13 Mar 2014 09:52:57 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 8FE8B2005D10B for ; Thu, 13 Mar 2014 09:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=+94YpNKbIPKOZWHjfl3B cYub7+Y=; b=Bu64y0U4P7HMdiZTtJiNPLuzciRILPnPQEawkWvJt2BJv7EG8PRi 6P6Cb0dDulHrRjtU36sGvj5bRIoQmU3dfdNJ0FkqWnKchznLKHclwRd16pQpvZpI OjeUUxhnwkH+ZqBZSsK4dUeTNyEyec2sWuxP/tKPpe7K2RLxYo+oxeg= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id 44C5A2005D10A for ; Thu, 13 Mar 2014 09:52:51 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id x48so1081748wes.7 for ; Thu, 13 Mar 2014 09:52:50 -0700 (PDT) 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=CsJrpTRArllw4k3WwRrOpdyn96uNGQD3uW9tvtyEN+E=; b=AsYjheW5JdgA1DJasyL+zhtXsELN0178K5r9Hm5nd93ErO6zzEdezIyuzHLhFlGVMh TGT4ymMLc66CuHabvFtt1OKHglv9cq25XkXOSFUvD8CcbLOH7D4HDrcXtnN0/BAT5DWO 8Lhi757gjVfhnQ9RgFdgOyo05rV3Uf25PTzcgn8DGjhI46t0zQZWIGlqkVPkv1FO2stk LgOT1X6JZzBdYZEe1GyA1aSqMKSNoUSi53qAILSSUSVT0p413VawzkKwRc7u6VK6bByI OHk9o1nG+wHx+KzEGZn4Vb3N4XQNf1VyWgFvpSLmidJQQb6SIGj0j13AwgGgBGYgEoMb l9eA== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr2403875wib.39.1394729570035; Thu, 13 Mar 2014 09:52:50 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Thu, 13 Mar 2014 09:52:49 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Mar 2014 11:52:49 -0500 Message-ID: From: Nico Williams To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k8iyFVM3NwLXsbj7mhKn04yBLN4 Cc: "tls@ietf.org" Subject: Re: [TLS] Thoughts on TLS 1.3 cryptography performance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 16:52:59 -0000 On Thu, Mar 13, 2014 at 11:48 AM, Eric Rescorla wrote: > On Thu, Mar 13, 2014 at 9:34 AM, Nico Williams > wrote: >> >> But I am concerned about the need for PFS on >> resumption in order to limit the extent of resumption ticket cache >> compromise; if you're going to lose the 0-RTT resumption for it, might >> as well pick the best "fast reauthentication" protocol possible, and >> that might be Watson's. > > > WRT this specific point, I wanted to observe that computational cost > (within reason) is less important than round trip delay, for a number of > reasons: My concern is in the sense of "this needs to be a security consideration, and Watson's protocol is worth considering at least as an option" (modulo IPR, if any). Nico -- From nobody Thu Mar 13 10:04:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739E51A0A27 for ; Thu, 13 Mar 2014 10:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] 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 P1VX5zzY4aAG for ; Thu, 13 Mar 2014 10:04:51 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (unknown [69.163.253.166]) by ietfa.amsl.com (Postfix) with ESMTP id C205B1A09EC for ; Thu, 13 Mar 2014 10:04:51 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 7F419778075 for ; Thu, 13 Mar 2014 10:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=9ptPxQI8eJkTsT1sPefK2Vd nS9I=; b=gwODXhHwex0lUjbXWo8On3VHNCRKqrduMSD05b4sE1s5xtjRB6LqfRQ IBuSBpBJX+2aHRUtZro/4VauKPBblq9rOzzIDMjL6Xgbny3IKg5Tl6KuoFOzltBG T3K5GNehQMyPNgvyHq8CiX3KuY6O8epgBPcTO3qgNZW3Nq1W2UIc= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 2F6E1778071 for ; Thu, 13 Mar 2014 10:04:44 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so1450774wiw.11 for ; Thu, 13 Mar 2014 10:04:42 -0700 (PDT) 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=NVDWwJsg8/LAnh2O/Y6MDDomHmRKF8D+/FjkG2gTPzA=; b=XER6Hhw2KhhUgeGLvXGHhhiP2LroyYktN8bXDSzXzXFY/iNhmIPZzbrFGjJRwiHw69 DIK6uqueTi68jcXTB1AY4QMXt6IyPUhCbOo1rTwkQIjgFLkRfh9sE/ymT/bsKnQkGLaS YRenbZ4fudo5u/a5eI0oFhgHqe1qr7lo2ey6K7L+EHNJO137kPCLeIwCrObD6trU8hOa UPQhENN99r/LR775fHFwFI/kr7tL3jWsQAUqzZ2KYmRic+kVFRAqYj51BO9F/5UVEYYb +c0Rq8f+Ce6q+i4GH3Qn0pHEaXdT283kVKkZ4uso40ozRmVJ5sMo+jsqUQaM7jpOfFmf YPSA== MIME-Version: 1.0 X-Received: by 10.194.84.240 with SMTP id c16mr90834wjz.95.1394730282877; Thu, 13 Mar 2014 10:04:42 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Thu, 13 Mar 2014 10:04:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Mar 2014 12:04:42 -0500 Message-ID: From: Nico Williams To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TZYto5Vg22J_SAuXqAnpAsChU7E Subject: Re: [TLS] I-D for ECDH anon AES AEAD ciphersuite registration (Fwd: New Version Notification ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 17:04:54 -0000 -01 posted. From nobody Thu Mar 13 10:17:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D531A0499 for ; Thu, 13 Mar 2014 10:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kvvitwk09MvC for ; Thu, 13 Mar 2014 10:17:24 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 88DD21A0A33 for ; Thu, 13 Mar 2014 10:17:24 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id bs8so1474272wib.2 for ; Thu, 13 Mar 2014 10:17:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Tr4s4qRYkI50oPcaktdT2yMl95spVMtVzuP+2cxt0FE=; b=FwDiT1hCQX9EHvfEnvwYpgsbak0o/+zPN/SiZsZM2q+Y1BhhabgFGbL7IeVAbnh18S U33sAOUpKTspuxcPLCcdSh9jgCtlVbgD9ktQxv8ZzYrP6XOnQhwahD1SY4Lq3RfpI5iA HzG3H+jOqDVQGXSMJ3FuAiAajV/20htb5BpDckdoXTAZTtKZawfN5tcVDQAvT4yq2T9s AY3hWVp5DHt9qh/l9YxZ0rq4KU9PUjl87UTk+oAN34m6Aq0l/EP27V6p6m1nKIaZwzHw umvN6Oy/QRoKXgXdjP1VVwuNIsgW2kqO2LvzEM5EJItzwhJEnhHUXHLfKgksDyUsemv1 0fXQ== X-Gm-Message-State: ALoCoQnbonc0d/ym4zRyDCQkhl0Jg61PqxSXfYSGJ12kH0VaP4AoS2fU2cPfRhLt4QFHT2pGFSZp MIME-Version: 1.0 X-Received: by 10.180.79.7 with SMTP id f7mr2592896wix.20.1394731037532; Thu, 13 Mar 2014 10:17:17 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Thu, 13 Mar 2014 10:17:17 -0700 (PDT) X-Originating-IP: [184.23.29.222] In-Reply-To: References: Date: Thu, 13 Mar 2014 10:17:17 -0700 Message-ID: From: Trevor Perrin To: Eric Rescorla Content-Type: multipart/alternative; boundary=f46d041825ea0cc07504f4802017 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6OB_hPqXL3PPR_rTIRGhih4zfRg Cc: "tls@ietf.org" Subject: Re: [TLS] Thoughts on TLS 1.3 cryptography performance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 17:17:28 -0000 --f46d041825ea0cc07504f4802017 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 13, 2014 at 9:48 AM, Eric Rescorla wrote: > On Thu, Mar 13, 2014 at 9:34 AM, Nico Williams wrote: > >> But I am concerned about the need for PFS on >> resumption in order to limit the extent of resumption ticket cache >> compromise; if you're going to lose the 0-RTT resumption for it, might >> as well pick the best "fast reauthentication" protocol possible, and >> that might be Watson's. > > > WRT this specific point, I wanted to observe that computational cost > (within reason) is less important than round trip delay > True, but a 0-RTT session ticket resumption requires less computation than a 0-RTT handshake based on a semi-static ECDH key (like QUIC, or your draft) without any RTT tradeoff. (My understanding of both QUIC and your draft is that in the 0-RTT case they perform an "overlaid" DH while exchanging application data in the initial RT, so subsequent data gets PFS while the initial RT does not. This could be done with session tickets as well.) Also: if the semi-static handshake is going to require an expensive client re-authentication (ChannelID, PAKE, a slow smartcard, etc.), then the savings for resumption are even greater. Trevor --f46d041825ea0cc07504f4802017 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Thu, Mar 13, 2014 at 9:48 AM, Eric Rescorla <ekr@rtfm.com> wro= te:
On Thu, Mar 13, 2014 at 9:34 AM, Nico Williams <nico@crypt= onector.com> wrote:
=A0But I am concerned about the need for PFS on
resumption in order to limit the extent of resumption ticket cache
compromise; if you're going to lose the 0-RTT resumption for it, might<= br> as well pick the best "fast reauthentication" protocol possible, = and
that might be Watson's.

WRT this = specific point, I wanted to observe that computational cost
(with= in reason) is less important than round trip delay

True, but a 0-RTT session ticket resu= mption requires less computation than a 0-RTT handshake based on a semi-sta= tic ECDH key (like QUIC, or your draft) without any RTT tradeoff.

(My understanding of both QUIC and your draft is that i= n the 0-RTT case they perform an "overlaid" DH while exchanging a= pplication data in the initial RT, so subsequent data gets PFS while the in= itial RT does not. =A0This could be done with session tickets as well.)

Also: if the semi-static handshake is going to require = an expensive client re-authentication (ChannelID, PAKE, a slow smartcard, e= tc.), then the savings for resumption are even greater.


Trevor

--f46d041825ea0cc07504f4802017-- From nobody Thu Mar 13 10:27:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172FF1A0A36 for ; Thu, 13 Mar 2014 10:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxT2A6Njtliv for ; Thu, 13 Mar 2014 10:27:55 -0700 (PDT) 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 E0E6D1A09FC for ; Thu, 13 Mar 2014 10:27:54 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id p61so1121928wes.25 for ; Thu, 13 Mar 2014 10:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RNmTsNcTPMYwz/ReE9rTmm6BW9DerKG8jAHRNj2mn24=; b=Lg9lp4hw10vGvjVRyBGFwP7eqsNW7UaBF9dbabU/OX9gAi04JkvKxGVn/TtbjEmbQt pmuGr2xFBJ1sHPSJ7djI8IocuiNxciFUmoi0O9kgHALStk55/ccOgXcjmADXYR9u8esy gzaaXbmIq13w9hXeULvTlOLo1iYZX+78+bOZyzmElKpyaJUkJ4dBO9KfVxuDDZJw59RO QSq09jueU68kGQz+uKK6bTFS8uGAQRRGKkUZUQqpfRcZ/GbFKrqHuu5GWhuU91Z14nMy zARRbhhbz5sUTAk6IZ4hG7BZMlW/ohy7tcJHdouDTzhtW66XqnIi5Ut0/vJ4HVDO0dGz 6Z1Q== MIME-Version: 1.0 X-Received: by 10.180.92.196 with SMTP id co4mr2590749wib.50.1394731667938; Thu, 13 Mar 2014 10:27:47 -0700 (PDT) Received: by 10.227.10.196 with HTTP; Thu, 13 Mar 2014 10:27:47 -0700 (PDT) Date: Thu, 13 Mar 2014 10:27:47 -0700 Message-ID: From: Martin Thomson To: "draft-ietf-tls-applayerprotoneg@tools.ietf.org" , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bf5nsbYuSi94bgJ9EgF25L9PdZM Subject: [TLS] Mentioning DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 17:27:57 -0000 It's a minor point, but ALPN only mentions UDP once (in the abstract) and DTLS not at all. I have to assume that DTLS is an intended part of this, but others have been confused by the lack of mention. Could this be corrected? A mention of DTLS in the first line of the introduction should suffice. From nobody Thu Mar 13 10:29:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885391A0A19 for ; Thu, 13 Mar 2014 10:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXpw93wlqmuF for ; Thu, 13 Mar 2014 10:29:14 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9441A0492 for ; Thu, 13 Mar 2014 10:29:14 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f10so1358937yha.38 for ; Thu, 13 Mar 2014 10:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q4JomVBoWMnjb+H7vYdZq7sYI01JK494lntv1OQpCaw=; b=KELkxJ9KSaII2qQPjaqEDAjtR/1pefsIalWRNRY/2n9/6/He+RoX5qJFFS0Ol/JsV7 AM5ba2Ll8AgKlcO+/3z76VgUe3e6qB3C7ykpkw+oGCNVZjh3Lhy1+Q0ZG15Sc//b6XOd /AVO4I1Ysmti6eeT02BM0WnwxXlOxJr6WTg0Gfjftg1vDGVHwfOgnttWJuE5Qapol7lr oifz0bn208eU9t2jIc6g3aoWGmUo5ql8w+oT+mRw0A9EVC55dFLELony4KJTcYxc/NK8 PdnJfVSVpPskpbYd3dOgYGuW+IIwT8OtpvBInX3tVRTR8JhntZtSp7mkZo4jov0hGP76 eevQ== MIME-Version: 1.0 X-Received: by 10.236.90.12 with SMTP id d12mr3941234yhf.120.1394731747574; Thu, 13 Mar 2014 10:29:07 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Thu, 13 Mar 2014 10:29:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Mar 2014 10:29:07 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tkl2Yb_7nVP02niHSWpcIfN_cUs Cc: "tls@ietf.org" Subject: Re: [TLS] Thoughts on TLS 1.3 cryptography performance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 17:29:15 -0000 On Thu, Mar 13, 2014 at 9:52 AM, Nico Williams wrote: > On Thu, Mar 13, 2014 at 11:48 AM, Eric Rescorla wrote: >> On Thu, Mar 13, 2014 at 9:34 AM, Nico Williams >> wrote: >>> >>> But I am concerned about the need for PFS on >>> resumption in order to limit the extent of resumption ticket cache >>> compromise; if you're going to lose the 0-RTT resumption for it, might >>> as well pick the best "fast reauthentication" protocol possible, and >>> that might be Watson's. >> >> >> WRT this specific point, I wanted to observe that computational cost >> (within reason) is less important than round trip delay, for a number of >> reasons: > > My concern is in the sense of "this needs to be a security > consideration, and Watson's protocol is worth considering at least as > an option" (modulo IPR, if any). Triple DH is unpatented AFAIK. MQV patent expires soon, but I don't like it. With Triple DH we can use genus 2 for even more speed, and when Kim Laine finishes his PhD, genus 3. Genus 3 is amazing because the arithmetic is modulo a 64 bit prime. We can't do higher genus stuff+MQV because of the lack of an addition formula on the compact forms. Sincerely, Watson Ladd > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Mar 13 10:46:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A2E1A0A16 for ; Thu, 13 Mar 2014 10:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojQdxmCPVivi for ; Thu, 13 Mar 2014 10:46:31 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 154CC1A0A33 for ; Thu, 13 Mar 2014 10:46:30 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id n15so3893167wiw.5 for ; Thu, 13 Mar 2014 10:46:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vnQAuZPm9hNNPYydHaE6b8s3CWF8LCblaD9SyrbKIhk=; b=iCUiwFxooofgeXZ8CTYWBR3jXofqSzaA99CAOEDfWs+FvMV2jaU7kWlRzRWpo6qka2 8Mtp8wM9Nw/j/Qz100KuMgQBoTM2Ge9uWYlq7JRG/tYj2URaox+bepMbLLrTEMFU2dWx AYvdxn0HfrWU4KlJLZvCSh6oBtpu8kzPSB2F7Q7qT96tv1pxaves8R5uyZ9gdywhNrdQ JhzGu5s9uOdc29O3KR3yvf9dE8p+KCDF1PV9oty2BLwNBSMVIIGLSBsyKCVY4dkuiAwX +Ne8mdwSa5L5i/oBBdfjLVYB8o0pqylfgw2f9d5BN+fS1x1QVm1zH8cvHSdDCqaKrU+X kCHQ== X-Gm-Message-State: ALoCoQnM7WXqu77qzZ8AhHk/rqH7NfiFli9Gkr8oKKWqKxiwppfDvOyRAb7gqNDlkxXWwx8McRGi MIME-Version: 1.0 X-Received: by 10.194.60.16 with SMTP id d16mr2770362wjr.46.1394732784068; Thu, 13 Mar 2014 10:46:24 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Thu, 13 Mar 2014 10:46:24 -0700 (PDT) X-Originating-IP: [184.23.29.222] In-Reply-To: References: Date: Thu, 13 Mar 2014 10:46:24 -0700 Message-ID: From: Trevor Perrin To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7b86ccbc26bf6e04f48088b6 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bHm924M-mtO52pmYLchQDzmqH6s Cc: "tls@ietf.org" Subject: Re: [TLS] Thoughts on TLS 1.3 cryptography performance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 17:46:33 -0000 --047d7b86ccbc26bf6e04f48088b6 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 13, 2014 at 10:29 AM, Watson Ladd wrote: > On Thu, Mar 13, 2014 at 9:52 AM, Nico Williams > wrote: > > On Thu, Mar 13, 2014 at 11:48 AM, Eric Rescorla wrote: > >> On Thu, Mar 13, 2014 at 9:34 AM, Nico Williams > >> wrote: > >>> > >>> But I am concerned about the need for PFS on > >>> resumption in order to limit the extent of resumption ticket cache > >>> compromise; if you're going to lose the 0-RTT resumption for it, might > >>> as well pick the best "fast reauthentication" protocol possible, and > >>> that might be Watson's. > >> > >> > >> WRT this specific point, I wanted to observe that computational cost > >> (within reason) is less important than round trip delay, for a number of > >> reasons: > > > > My concern is in the sense of "this needs to be a security > > consideration, and Watson's protocol is worth considering at least as > > an option" (modulo IPR, if any). > > Triple DH is unpatented AFAIK. MQV patent expires soon It's a little more complex than this. I think HMQV has a patent from IBM as well as the Certicom MQV patents. Triple DH itself is unpatented and derives from [1,2]. But when hashing identity information into the session key, Microsoft's KEA+ patent (which covers doing this with a "Double DH") might possibly be viewed as relevant. (I think that's an obvious combination of prior art, and arguably not directly relevant. But it creates some uncertainty.) Trevor [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.27.8493 [2] http://www.iacr.org/cryptodb/archive/2005/ASIACRYPT/283/283.pdf --047d7b86ccbc26bf6e04f48088b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Thu, Mar 13, 2014 at 10:29 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
On Thu, Mar 13, 2014 at = 9:52 AM, Nico Williams <nico@cr= yptonector.com> wrote:
> On Thu, Mar 13, 2014 at 11:48 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>> On Thu, Mar 13, 2014 at 9:34 AM, Nico Williams <nico@cryptonector.com>
>> wrote:
>>>
>>> =A0But I am concerned about the need for PFS on
>>> resumption in order to limit the extent of resumption ticket c= ache
>>> compromise; if you're going to lose the 0-RTT resumption f= or it, might
>>> as well pick the best "fast reauthentication" protoc= ol possible, and
>>> that might be Watson's.
>>
>>
>> WRT this specific point, I wanted to observe that computational co= st
>> (within reason) is less important than round trip delay, for a num= ber of
>> reasons:
>
> My concern is in the sense of "this needs to be a security
> consideration, and Watson's protocol is worth considering at least= as
> an option" (modulo IPR, if any).

Triple DH is unpatented AFAIK. MQV patent expires soon

It's a little more complex than this.

I think HMQV has a patent from IBM as well as the Cert= icom MQV patents.

Triple DH itself is unpatented and derives from [1,2]. = =A0But when hashing identity information into the session key, Microsoft= 9;s KEA+ patent (which covers doing this with a "Double DH") migh= t possibly be viewed as relevant.

(I think that's an obvious combination of prior art= , and arguably not directly relevant. =A0But it creates some uncertainty.)<= /div>


Trevor


--047d7b86ccbc26bf6e04f48088b6-- From nobody Thu Mar 13 11:03:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425EB1A0A4B for ; Thu, 13 Mar 2014 11:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xkUU2SsiHpn for ; Thu, 13 Mar 2014 11:03:00 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF521A0A53 for ; Thu, 13 Mar 2014 11:02:59 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t61so1188791wes.31 for ; Thu, 13 Mar 2014 11:02:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=crQzIy3gaaRiYyTbHGZkrlIWIuR3g7FwcRyqojp4CmE=; b=hXNFHz6IRuueaApiFgEAb3hCtjVRmjhnp4pPd4ewlECjqdcvJ3SM+4vC58IMyQH4Is uWVgRl+1nD1P/0HLdDIUgrkJuGUKNNdZDHYn8aBMr+z9DRZcybkAr3smI2I0stZM7fH7 vuT9wOtXiu7M73uiWGpTw/kU6HHYDcfyo2Dk8tZUQH9PFtRpSDKdf/bmF5ZCbPj7e/u8 pqWYCq3ppBkqbBxyMFiKvesnBv48xABgVxGT/3VYDq2XLU0wOQxkVFGHmdoDJdYc9ns0 tX4bmZKRO+DywPlOjTcC3NlzWgXiqjbuatK1wMc8CurbpZXs2BZMViSkePy6ks8gPkBW RllQ== X-Gm-Message-State: ALoCoQltOyWwr7zM+s7kg7SHkmZvCdB2NiYPywcmaxySy1hn9s0NmED8eppgsZQt69zKFjNn6uk9 X-Received: by 10.180.164.174 with SMTP id yr14mr2750228wib.18.1394733773075; Thu, 13 Mar 2014 11:02:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Thu, 13 Mar 2014 11:02:12 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: References: From: Eric Rescorla Date: Thu, 13 Mar 2014 11:02:12 -0700 Message-ID: To: Trevor Perrin Content-Type: multipart/alternative; boundary=00248c0d791419d98f04f480c3eb Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-ElzGW8wbiDbnh2avNSjAPMKXmY Cc: "tls@ietf.org" Subject: Re: [TLS] Thoughts on TLS 1.3 cryptography performance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 18:03:02 -0000 --00248c0d791419d98f04f480c3eb Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 13, 2014 at 10:17 AM, Trevor Perrin wrote: > > On Thu, Mar 13, 2014 at 9:48 AM, Eric Rescorla wrote: > >> On Thu, Mar 13, 2014 at 9:34 AM, Nico Williams wrote: >> >>> But I am concerned about the need for PFS on >>> resumption in order to limit the extent of resumption ticket cache >>> compromise; if you're going to lose the 0-RTT resumption for it, might >>> as well pick the best "fast reauthentication" protocol possible, and >>> that might be Watson's. >> >> >> WRT this specific point, I wanted to observe that computational cost >> (within reason) is less important than round trip delay >> > > True, but a 0-RTT session ticket resumption requires less computation than > a 0-RTT handshake based on a semi-static ECDH key (like QUIC, or your > draft) without any RTT tradeoff. > > (My understanding of both QUIC and your draft is that in the 0-RTT case > they perform an "overlaid" DH while exchanging application data in the > initial RT, so subsequent data gets PFS while the initial RT does not. > This could be done with session tickets as well.) > Thanks for making this point. I think it gets to precisely the questions we need to be asking, namely: 1. Do we want to provide a mechanism for a client and server to form a new TLS connection without doing any public key operations? 2. Do we want to provide a mechanism for a client and server to do a 0-RTT handshake which minimizes the number of public key operations, potentially at the cost of linkability. (It's possible to do a 0-RTT handshake without linkability if the server uses the same DH key for a lot of clients, but not if you use the same session ticket repeatedly, though maybe you could swap the ticket each time.) -Ekr > Also: if the semi-static handshake is going to require an expensive client > re-authentication (ChannelID, PAKE, a slow smartcard, etc.), then the > savings for resumption are even greater. > > > Trevor > > --00248c0d791419d98f04f480c3eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 13, 2014 at 10:17 AM, Trevor Perrin &= lt;trevp@trevp.net= > wrote:
=
On Thu, Mar 13, 2014 at 9:48= AM, Eric Rescorla <ekr@rtfm.com> wrote:
On Thu, Mar 13, 2014 at 9:34 AM, Nico Williams <nico@cryptonector.com= > wrote:
=A0But I am concerned about the need for PFS on
resumption in order to limit the extent of resumption ticket cache
compromise; if you're going to lose the 0-RTT resumption for it, might<= br> as well pick the best "fast reauthentication" protocol possible, = and
that might be Watson's.

WRT this = specific point, I wanted to observe that computational cost
(with= in reason) is less important than round trip delay

True, but a 0-RTT session ticke= t resumption requires less computation than a 0-RTT handshake based on a se= mi-static ECDH key (like QUIC, or your draft) without any RTT tradeoff.

(My understanding of both QUIC and your draft is that i= n the 0-RTT case they perform an "overlaid" DH while exchanging a= pplication data in the initial RT, so subsequent data gets PFS while the in= itial RT does not. =A0This could be done with session tickets as well.)

Thanks for making = this point. I think it gets to precisely the questions we need
to= be asking, namely:

1. Do we want to provide a mec= hanism for a client and server to form a new
TLS connection without doing any public key operations?

=
2. Do we want to provide a mechanism for a client and server to = do a
0-RTT handshake which minimizes the number of public key ope= rations,
potentially at the cost of linkability. (It's possible to do a 0-R= TT handshake
without linkability if the server uses the same DH k= ey for a lot of clients,
but not if you use the same session tick= et repeatedly, though maybe you
could swap the ticket each time.)

-Ekr
<= div>=A0
Also: if the semi-static handshake is = going to require an expensive client re-authentication (ChannelID, PAKE, a = slow smartcard, etc.), then the savings for resumption are even greater.


Trevor


--00248c0d791419d98f04f480c3eb-- From nobody Thu Mar 13 11:36:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646C91A07AD for ; Thu, 13 Mar 2014 11:36:43 -0700 (PDT) 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 ao1GORZbyceX for ; Thu, 13 Mar 2014 11:36:42 -0700 (PDT) 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 0A62C1A0729 for ; Thu, 13 Mar 2014 11:36:41 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p61so1236907wes.27 for ; Thu, 13 Mar 2014 11:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=24ko+Esi/kwTiquE8glzarf8yMq6yEgD7ztVGaMcVrc=; b=m5MUjAsovgiI1Udl/BA1iKuuUy3svOXFyUkK1vbyGa1SYA+mRsLrZMMIeD97e3xPmL cT6gPipYKF2ThJggAXJCBitoGhdsqa72I3HiyARGAjf2NGPWqaZx7KAc1jz0LXTQNMcb Zn6GujKqHi1OkDZc7gFSzY57t0n/uXvpaTYCCbzV8gLxJA3VNN4uxTi5oCfgHzAauifJ RdDNBVVQYE4k3kDov/oTaIQhki3ReEKj6n1bNXXt3DLoE6zuiwWSWPpj8Y97T9Wl4DmD 18Aljlo7n5V4lz5wwbdI7emFhpkXDf7Ucej7pmYOGui15D2Q2Csj0Ku3HKtOHWBudTBf 2w+Q== X-Received: by 10.180.13.197 with SMTP id j5mr2897496wic.14.1394735794953; Thu, 13 Mar 2014 11:36:34 -0700 (PDT) Received: from [10.0.0.4] ([109.64.6.27]) by mx.google.com with ESMTPSA id v6sm9711838wif.0.2014.03.13.11.36.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 11:36:34 -0700 (PDT) Message-ID: <5321FAB1.2070309@gmail.com> Date: Thu, 13 Mar 2014 20:36:33 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nico Williams , =?ISO-8859-1?Q?Manuel_P=E9go?= =?ISO-8859-1?Q?uri=E9-Gonnard?= References: <532024EF.4060607@polarssl.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/z_OEQAYl_82byR2WZAEx_2rY4rg Cc: "tls@ietf.org" Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 18:36:43 -0000 Hi Nico, this is about much more than anon-DH cipher suites. The proposal that if the client doesn't see a DANE certificate, it can initiate a TLS connection with (only) anon-DH means that even if the server does have a PKIX certificate (maybe it's old and has not heard of TLSA yet:-), the client will not be able to get an authenticated connection with it. So we will probably need these cipher suites combined with additional TLS signaling, as well as certificate pinning, to allow clients to juggle securely between authenticated and anonymous TLS. Thanks, Yaron On 03/13/2014 07:02 AM, Nico Williams wrote: [...] > > In the SMTP case when there's no TLSA RRs in the DNS for the server > and the server has no certificates, the client may prefer to use anon > DH/ECDH. Considering that e-mail has historically had very poor > privacy protection, that would be a huge step up. But today an SMTP > client can't get high-performance ECDH and AEAD ciphers :( From nobody Thu Mar 13 12:08:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C181A0774 for ; Thu, 13 Mar 2014 12:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncOUZZmnhavK for ; Thu, 13 Mar 2014 12:08:24 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (agjbgdcfdbec.dreamhost.com [69.163.253.142]) by ietfa.amsl.com (Postfix) with ESMTP id 309EC1A0155 for ; Thu, 13 Mar 2014 12:08:24 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id C68EC2005D910 for ; Thu, 13 Mar 2014 12:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=aEDT1f1t0WQqOD9fVucR gHcqFgY=; b=Nh577+QzYwdlDm94/Jk7VvbOCFPzo83ZmlWKT9RaBZK3Ct4hj89K r7mcxGD3i0rRPD7iedbnJ9JJ01D+LrhPafCsR/NAQahSCjhHHCm4GVzbyHjl/fdU GARLwx4iCiOA3XhoIPAYmocM3DcUezuPXq/y3XxK64Ra8DlgHqCRfU0= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id 7A4CB2005D90B for ; Thu, 13 Mar 2014 12:08:17 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so1241717wgg.21 for ; Thu, 13 Mar 2014 12:08:16 -0700 (PDT) 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=P7PmKOKB3E2RZ2WJbcV4uhkXSibJldxP2ydF8NZe+aI=; b=luDfoaLDGEKsm0XZ5T6fDceNwEn341DF1duDZiGGpmuYuAV51AjPjcL6jZUizUgaz1 FxF4N8mEsFPagPB7i89imKwFmj/orCv8/xYl5B7TQ/NcYMrE+BN0SKQtY9v2xpxc4YZr z5qngrdK83jRqErYZ32PtHkdJzUU/BTVeDMokGn5sgfBII9LSfNdCELzyWN2TpMonBGs LdCa/X9X0KnFkg1C8dKpy4Zrgw18GJTbAs+AqeqR3LNzR18gUghLWm2s9q2wqlkuFxpU ShpEssgEsETlo4QS1JCQ84K7HV1/61plz9aQoM8i2OoA0b69OIeryc7Zpp0ZaBqzT+2M DLmg== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr2889992wib.39.1394737696371; Thu, 13 Mar 2014 12:08:16 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Thu, 13 Mar 2014 12:08:16 -0700 (PDT) In-Reply-To: <5321FAB1.2070309@gmail.com> References: <532024EF.4060607@polarssl.org> <5321FAB1.2070309@gmail.com> Date: Thu, 13 Mar 2014 14:08:16 -0500 Message-ID: From: Nico Williams To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZTzj22BmKC5HSAfF2GpLgql09lU Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , "tls@ietf.org" Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 19:08:25 -0000 On Thu, Mar 13, 2014 at 1:36 PM, Yaron Sheffer wrote: > this is about much more than anon-DH cipher suites. [...] Other anon ciphersuites exist. We should register these missing ones. What rationale is there for not doing so? As to how to use them, that's a general and _orthogonal_ issue. Nico -- From nobody Thu Mar 13 12:24:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1911A09B3 for ; Thu, 13 Mar 2014 12:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3LGE9BtZa-W for ; Thu, 13 Mar 2014 12:23:59 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBBE1A0990 for ; Thu, 13 Mar 2014 12:23:59 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s2DJNjBJ018049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Mar 2014 20:23:45 +0100 (MET) In-Reply-To: <5321FAB1.2070309@gmail.com> To: Yaron Sheffer Date: Thu, 13 Mar 2014 20:23:45 +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: <20140313192345.5F4D91AC4A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8iQwUchV0J2z25ylu8Bb8IPr6GY Cc: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , "tls@ietf.org" Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx 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, 13 Mar 2014 19:24:04 -0000 I strongly frown upon the idea of resurrecting DH_anon cipher suites from their cold grave, let alone adding new cruft. Generate Server Keys on the fly just like SSH does. Resurrecting DH_anon turns an initial-leap-of-faith into eternal-leaps-of-faith. -Martin Yaron Sheffer wrote: > > this is about much more than anon-DH cipher suites. The proposal that if > the client doesn't see a DANE certificate, it can initiate a TLS > connection with (only) anon-DH means that even if the server does have a > PKIX certificate (maybe it's old and has not heard of TLSA yet:-), the > client will not be able to get an authenticated connection with it. So > we will probably need these cipher suites combined with additional TLS > signaling, as well as certificate pinning, to allow clients to juggle > securely between authenticated and anonymous TLS. > > Thanks, > Yaron > > On 03/13/2014 07:02 AM, Nico Williams wrote: > [...] > > > > > In the SMTP case when there's no TLSA RRs in the DNS for the server > > and the server has no certificates, the client may prefer to use anon > > DH/ECDH. Considering that e-mail has historically had very poor > > privacy protection, that would be a huge step up. But today an SMTP > > client can't get high-performance ECDH and AEAD ciphers :( From nobody Thu Mar 13 12:25:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B623E1A07D9 for ; Thu, 13 Mar 2014 12:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyEGStzMgZdF for ; Thu, 13 Mar 2014 12:25:37 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 38F291A0729 for ; Thu, 13 Mar 2014 12:25:37 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so1634841wiw.12 for ; Thu, 13 Mar 2014 12:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Oz1OvrAeF8doSkEf/weQOGuTK9hiYgUUYats4JOTLMA=; b=mHr+UJLtymK2a55/jb748XlDUzzKFje822tzP0+OGZQBVAN+F5kqqujGw4OFv9A1VK fUDLIjz6Bk/D9Mh88kZxOv5yYvJrhOVWmhTEP72PZXlyHswg5uwRy+Txd7xRFDgzCqc2 UymKHTbVY5OWFzpALCuKXUIh8HaI3obIgHnJgpgiBrs0o1pwqV8zpRg3U9N6bHavf1vC xJcCoNntJ4WY5NzYPRcVR6mXKUk2RWXl8QvB9IBsr4nqkI96w+3morSne225c/HyMSMj cB8wUWfTicmIohG2d+flQMxZgP7cjfxA5XjgNCt1B8+u793gablgKe559yvpB9nofJbM 5deg== X-Received: by 10.180.189.169 with SMTP id gj9mr2989230wic.17.1394738730054; Thu, 13 Mar 2014 12:25:30 -0700 (PDT) Received: from [10.0.0.4] ([109.64.6.27]) by mx.google.com with ESMTPSA id ju6sm7944069wjc.1.2014.03.13.12.25.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 12:25:29 -0700 (PDT) Message-ID: <53220628.8020302@gmail.com> Date: Thu, 13 Mar 2014 21:25:28 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nico Williams References: <532024EF.4060607@polarssl.org> <5321FAB1.2070309@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EhN4HVGOYwpelUOyQTjpmEoQjGM Cc: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , "tls@ietf.org" Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 19:25:39 -0000 I fully agree. I was just saying that deploying them in real-life scenarios would require a more complete solution. Yaron On 03/13/2014 09:08 PM, Nico Williams wrote: > On Thu, Mar 13, 2014 at 1:36 PM, Yaron Sheffer wrote: >> this is about much more than anon-DH cipher suites. [...] > > Other anon ciphersuites exist. We should register these missing ones. > What rationale is there for not doing so? > > As to how to use them, that's a general and _orthogonal_ issue. > > Nico > -- > From nobody Thu Mar 13 12:30:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25201A0977 for ; Thu, 13 Mar 2014 12:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_RrER0JyPl6 for ; Thu, 13 Mar 2014 12:30:06 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (agjbgdcfdbfb.dreamhost.com [69.163.253.151]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFD21A066A for ; Thu, 13 Mar 2014 12:30:06 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id E153B2007E623 for ; Thu, 13 Mar 2014 12:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=c7WGjiReANZGRMhfTM0z ziRbQIw=; b=AZiiuyFxoA043nZ7Cgw1TNlno81/iaDCOAe3eNwqqS/xbWHVJtex 4+LbtId8w+EamvN2ToQdKgCcDEKSExLNhHByNJPdvgv++iWGAHPtqdSvx+xNy+19 2TjyMKLhYXlUagwxyVT5bEAzUr2oAgM+v1KsAl/PS30W103QrfUJLak= Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPSA id 95F652007E621 for ; Thu, 13 Mar 2014 12:29:59 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so1250928wes.23 for ; Thu, 13 Mar 2014 12:29:58 -0700 (PDT) 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=MvhAw5ufPLTmPW4OR8lrmshEytH/Z8E7ic/DNxgeAQg=; b=huvAobnhbwWS5kRjhWb3mEclD2qQCeooTs9kMPGo3sLjFbzg/LPc6evx/d0F+jQfBD mYUnVgykiuisNxSrKlnPeHgrMgpfrFYt8wfXzXszzzi6yEpzT5J7IjFtjTW7QlUM2/7b +RJAGESy+vRlRMYX6kRbbHXEe6fAhWqnkC0N+h0A05zEclHi4iAvULlewoKeJvOufmAJ xJZ/SS1g7nTFmrsB1W54XB1F5JIeS5SN/dGvg6IgdNlYztJjAkS5l3ibXUdxAQtX04sv TgfJ4LVa316nCQDS/IfDrD0zC6j5Qfw5zCEpX7e2oW/DDcNFyCB72HpypMlXRM8e8tr2 SFTw== MIME-Version: 1.0 X-Received: by 10.194.84.240 with SMTP id c16mr118716wjz.95.1394738998441; Thu, 13 Mar 2014 12:29:58 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Thu, 13 Mar 2014 12:29:58 -0700 (PDT) In-Reply-To: <20140313192345.5F4D91AC4A@ld9781.wdf.sap.corp> References: <5321FAB1.2070309@gmail.com> <20140313192345.5F4D91AC4A@ld9781.wdf.sap.corp> Date: Thu, 13 Mar 2014 14:29:58 -0500 Message-ID: From: Nico Williams To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vuDLwCzlnJbO_fEHUDHHPi0ugHY Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , "tls@ietf.org" Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 19:30:07 -0000 On Thu, Mar 13, 2014 at 2:23 PM, Martin Rex wrote: > I strongly frown upon the idea of resurrecting DH_anon cipher suites > from their cold grave, let alone adding new cruft. OK, but do you oppose it, and if so, on what grounds? Frowning is not really part of the consensus process :) > Generate Server Keys on the fly just like SSH does. Resurrecting > DH_anon turns an initial-leap-of-faith into eternal-leaps-of-faith. And if I want to renegotiate inside the tunnel? Why must I pay for extra crypto just because you frown? Nico -- From nobody Thu Mar 13 12:31:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DC61A0640 for ; Thu, 13 Mar 2014 12:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 Z7WijyQEqaAt for ; Thu, 13 Mar 2014 12:31:19 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (agjbgdcfdbgj.dreamhost.com [69.163.253.169]) by ietfa.amsl.com (Postfix) with ESMTP id 884581A03E2 for ; Thu, 13 Mar 2014 12:31:19 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 329771607 for ; Thu, 13 Mar 2014 12:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=RIvBTPuWT1g4By96xo8q Qiv/dsk=; b=eybAYkoGEUYfMBNbg2s8WEHPbQSyGn9ydVs1QLOUYD0os3KdnAgf FS9XO8w0CA5+vKpfMeRAW13YNxV1yb3ToFdSgWYJjDZInyAG4wAOy5hQuCUoC8P3 9nZyCrvaWmxcIUOJRpHC9icTjhtmYIw6N3ZRrfhWYAthj5dkS55zkGs= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id C5E561600 for ; Thu, 13 Mar 2014 12:31:12 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id x13so1265356wgg.2 for ; Thu, 13 Mar 2014 12:31:11 -0700 (PDT) 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=5xHDcyKmyZn4mTy/2JfjTJgY0801yH0XYl1U3WneNRM=; b=OKCYBV8pAustRWcGfAkr4iFLNZ/N+o4z7r0/KYQlOAnwjKsEUTY1Ef6QtVxBfazE3u AcFSlV3t5vBvu4ZzhjT15R4I8y/fyBQIDSe+/Z/Efv29pV9Q/lK67xsqIhEbRvmYlcMS AOYaMO/n7WGH6em3caqz/+hRGCk3YWvWA4PHkZ0ygMmP0rap4G1wVqdk0HXThGgB/S9l KrOIyLxWSusNW8bpwsajDWM8HIBlsX4coqst7pQV2bQne00+eMBE2JEW/+sOCxw41LL2 W8zmwD6Kixtltw6AD95CUxnezOob5i0lEip2zTPKyNXGFdgAxM2Z0vMQU4/F6+Q2Lp4m jj1Q== MIME-Version: 1.0 X-Received: by 10.180.102.42 with SMTP id fl10mr3030854wib.42.1394739071617; Thu, 13 Mar 2014 12:31:11 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Thu, 13 Mar 2014 12:31:11 -0700 (PDT) In-Reply-To: <53220628.8020302@gmail.com> References: <532024EF.4060607@polarssl.org> <5321FAB1.2070309@gmail.com> <53220628.8020302@gmail.com> Date: Thu, 13 Mar 2014 14:31:11 -0500 Message-ID: From: Nico Williams To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sSrAvFH8rk9T0nwbklfzOam7h9s Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , "tls@ietf.org" Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 19:31:21 -0000 On Thu, Mar 13, 2014 at 2:25 PM, Yaron Sheffer wrote: > I fully agree. I was just saying that deploying them in real-life scenarios > would require a more complete solution. Sure, but since you fully agree I gather you also fully agree that this is orthogonal to registering the missing ciphersuites. OK, so let's start a separate thread (new subject) to discuss the uses of anon ciphersuites. Nico -- From nobody Thu Mar 13 12:51:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124071A09FE for ; Thu, 13 Mar 2014 12:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gusXMjR7Hg1P for ; Thu, 13 Mar 2014 12:51:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1D11A0990 for ; Thu, 13 Mar 2014 12:51:48 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BN1PR03MB022.namprd03.prod.outlook.com (10.255.224.40) with Microsoft SMTP Server (TLS) id 15.0.898.11; Thu, 13 Mar 2014 19:51:39 +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.0893.001; Thu, 13 Mar 2014 19:51:39 +0000 From: Andrei Popov To: Martin Thomson , "draft-ietf-tls-applayerprotoneg@tools.ietf.org" , "tls@ietf.org" Thread-Topic: [TLS] Mentioning DTLS Thread-Index: AQHPPuGU3Od0CFfVvEChZAOgqFQEYZrfbTqA Date: Thu, 13 Mar 2014 19:51:38 +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: 01494FA7F7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(13464003)(199002)(189002)(164054003)(19580405001)(81342001)(2656002)(81686001)(81816001)(80976001)(83322001)(69226001)(19580395003)(81542001)(74876001)(56816005)(90146001)(15975445006)(87936001)(63696002)(79102001)(20776003)(80022001)(65816001)(33646001)(77982001)(59766001)(47446002)(74316001)(85306002)(74366001)(31966008)(74662001)(74502001)(74706001)(87266001)(76786001)(76796001)(76576001)(50986001)(54356001)(51856001)(97186001)(95416001)(47736001)(47976001)(93136001)(46102001)(49866001)(93516002)(94316002)(94946001)(92566001)(2201001)(4396001)(53806001)(86612001)(86362001)(76482001)(95666003)(83072002)(97336001)(56776001)(85852003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR03MB022; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:341EC5B1.703AFCA.AF6E31B7.9015DC71.20174; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/S9oVGyRLnrM-03ErFt8JrJUQ4sw Subject: Re: [TLS] Mentioning DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 19:51:50 -0000 Mentioning DTLS makes sense; I have no objection to making this change in t= he next revision. Thanks, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Thursday, March 13, 2014 10:28 AM To: draft-ietf-tls-applayerprotoneg@tools.ietf.org; tls@ietf.org Subject: [TLS] Mentioning DTLS It's a minor point, but ALPN only mentions UDP once (in the abstract) and D= TLS not at all. I have to assume that DTLS is an intended part of this, but others have bee= n confused by the lack of mention. Could this be corrected? A mention of DTLS in the first line of the introd= uction should suffice. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Mar 13 12:52:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43FD1A0A1B for ; Thu, 13 Mar 2014 12:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knbAV-cWSpeD for ; Thu, 13 Mar 2014 12:51:51 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 137461A0990 for ; Thu, 13 Mar 2014 12:51:50 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi5so4435418wib.17 for ; Thu, 13 Mar 2014 12:51:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4FEkY0qc2lGkUNPtOXifPddgth2HI07iNavDSdH8ym0=; b=fvApwwGIEjJ0hcj642uKStfRTkO5Yp4/ETQ4ao9IT/qjxzgjSxm4wXkdbLL7IrYW3B StSigDvUcvu1L8pN1KTFKUqS4v08iect4cKfj2/BtrBcmyUfa5Sl/JG6qdMZvniI+qRR 744cIosRN3rEAVLct6+qrGYJvEZE/MtigPHaQ60gkuQEVHChbswC+kgf29l1pZXE7x4H Jub07HE0A76U0YRw+XdnxYwtTSFi7ukoZjFJvvDxN57i++cHtuMQW1GfUhVFjZqpxDdf 3wWTBFwIKXZ3EzNWlJZ2vJREdqwcMS08NZUsprKy9W80TeWA5ZSMkU7b8hcRuSPdqEDI JnQQ== X-Gm-Message-State: ALoCoQkNOpA+E79QCMYuvz4lkQTHLOPHDNWcJ0jamRCVrsZ2rhWrJmo1cUS4xvOjlHKkPFX/UljS MIME-Version: 1.0 X-Received: by 10.194.185.148 with SMTP id fc20mr3252730wjc.27.1394740303990; Thu, 13 Mar 2014 12:51:43 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Thu, 13 Mar 2014 12:51:43 -0700 (PDT) X-Originating-IP: [184.23.29.222] In-Reply-To: <532080AD.6080907@cs.tcd.ie> References: <531F9443.1000002@cs.tcd.ie> <532080AD.6080907@cs.tcd.ie> Date: Thu, 13 Mar 2014 12:51:43 -0700 Message-ID: From: Trevor Perrin To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7bdcab7c5fa6b004f48248d2 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/np-UiIUiFtbONHuBbSoSS8zzMMY Cc: "tls@ietf.org" Subject: Re: [TLS] TLS chairing changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 19:51:54 -0000 --047d7bdcab7c5fa6b004f48248d2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 12, 2014 at 8:43 AM, Stephen Farrell wrote: > > Hi Trevor, > > On 03/12/2014 03:06 PM, Trevor Perrin wrote: > > On Tue, Mar 11, 2014 at 3:54 PM, Stephen Farrell > > wrote: > > > >> > >> Effective April 1st, Sean Turner will become a third TLS > >> co-chair in order to free up Eric who will be a TLS 1.3 > >> document editor. > > > > > > > > Hi Stephen, > > > > There was discussion about having a more competitive process for TLS 1.3 > > [1]. > > I'm not at all sure a "competition" is the right way to pick > an initial draft as a starting point. Of course, people are > free to write any I-D they choose and propose that to the WG, > but I think that the process being followed so far of discussing > the features and building from those seems to be going fine. > I thought EKR's drafts were more of a brainstorming / strawman to get people thinking about things [1,2]. I assumed at some point after re-chartering we'd discuss process, timelines, and requirements some more, and have an open process for TLS 1.3 candidates. Until your email, it wasn't made clear - at least to the list - that EKR's draft was the presumptive TLS 1.3. It's great that EKR's draft is driving discussion. But that draft makes many choices which may be optimal, or may not: * For an initial handshake, EKR's draft recommends a 2-RTT flow with 2 DH computations. I think it could also support a flow with 1-RTT, 2 DH, and reduced foward secrecy for the first RT of Application Data. This seems a step backwards from current TLS, which can support a False-Start handshake with 1-RTT, 1 DH, and full forward secrecy. * For a "reconnect" handshake, EKR's draft performs DH with a "semi-static" DH key. This is more computation than a traditional session-ticket resumption. * EKR's draft assumes we want to reuse TLS structures as much as possible, for simplicity. An alternative would be to design structures which are more different from TLS, but more simple in their own right. And there's a lot else to be decided wrt key agreement, ciphersuites, renegotiation, SNI, potential integration with (Client Auth, ChannelID, PAKE, TACK), etc. Anyways, I'd prefer a process where the WG held off from anointing a single draft as "the" TLS 1.3 WG item for several months, and invited individual contributions. Eric's draft would be such a contribution, but so could designs based on QUIC or MinimaLT, or anything else. This would let us to explore the design space via comparing and contrasting different designs. Once the WG was satisfied that it preferred one candidate, this would be made a WG item for finishing the spec. Trevor [1] http://www.ietf.org/mail-archive/web/tls/current/msg10404.html [2] http://www.ietf.org/mail-archive/web/tls/current/msg11300.html --047d7bdcab7c5fa6b004f48248d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Wed, Mar 12, 2014 at 8:43 AM, Stephen Farrell <stephen.farrell@= cs.tcd.ie> wrote:

Hi Trevor,

On 03/12/2014 03:06 PM, Trevor Perrin wrote:
> On Tue, Mar 11, 2014 at 3:54 PM, Stephen Farrell
> <stephen.farrell@cs.tc= d.ie>wrote:
>
>>
>> Effective April 1st, Sean Turner will become a third TLS
>> co-chair in order to free up Eric who will be a TLS 1.3
>> document editor.
>
>
>
> Hi Stephen,
>
> There was discussion about having a more competitive process for TLS 1= .3
> [1].

I'm not at all sure a "competition" is the right way to= pick
an initial draft as a starting point. Of course, people are
free to write any I-D they choose and propose that to the WG,
but I think that the process being followed so far of discussing
the features and building from those seems to be going fine.

I thought EKR's drafts were more of a brains= torming / strawman to get people thinking about things [1,2].

I assumed at some point after re-chartering we'd discuss= process, timelines, and requirements some more, and have an open process f= or TLS 1.3 candidates. =A0Until your email, it wasn't made clear - at l= east to the list - that EKR's draft was the presumptive TLS 1.3.

It's great that EKR's draft is driving discussi= on. =A0But that draft makes many choices which may be optimal, or may not:<= /div>

=A0* For an initial handshake, EKR's draft rec= ommends a 2-RTT flow with 2 DH computations. =A0I think it could also suppo= rt a flow with 1-RTT, 2 DH, and reduced foward secrecy for the first RT of = Application Data. =A0This seems a step backwards from current TLS, which ca= n support a False-Start handshake with 1-RTT, 1 DH, and full forward secrec= y.

=A0* For a "reconnect" handshake, EKR's d= raft performs DH with a "semi-static" DH key. =A0This is more com= putation than a traditional session-ticket resumption.

=A0* EKR's draft assumes we want to reuse TLS structures as much a= s possible, for simplicity. =A0An alternative would be to design structures= which are more different from TLS, but more simple in their own right.

And there's a lot else to be decided wrt key agreem= ent, ciphersuites, renegotiation, SNI, potential integration with (Client A= uth, ChannelID, PAKE, TACK), etc.

Anyways, I'd= prefer a process where the WG held off from anointing a single draft as &q= uot;the" TLS 1.3 WG item for several months, and invited individual co= ntributions. =A0Eric's draft would be such a contribution, but so could= designs based on QUIC or MinimaLT, or anything else.

This would let us to explore the design space via compa= ring and contrasting different designs. =A0Once the WG was satisfied that i= t preferred one candidate, this would be made a WG item for finishing the s= pec.


Trevor


--047d7bdcab7c5fa6b004f48248d2-- From nobody Thu Mar 13 13:01:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2B11A072A for ; Thu, 13 Mar 2014 13:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ypo3g4bz5EkX for ; Thu, 13 Mar 2014 13:00:57 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 90CEC1A07D9 for ; Thu, 13 Mar 2014 13:00:57 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id C3C8D1C21FA; Thu, 13 Mar 2014 21:00:49 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id A26461FE01C3; Thu, 13 Mar 2014 21:00:49 +0100 (CET) Date: Thu, 13 Mar 2014 21:00:49 +0100 From: Kurt Roeckx To: mrex@sap.com (Martin Rex) Message-ID: <20140313200049.GA28402@roeckx.be> References: <5321FAB1.2070309@gmail.com> <20140313192345.5F4D91AC4A@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140313192345.5F4D91AC4A@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.22 (2013-10-16) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zyy5XMBmpkSS_g1IqRmup3wD2-Y Cc: =?iso-8859-1?Q?P=E9gouri=E9-Gonnard_=3Cmpg=40polarssl=2Eorg=3E?=@roeckx.be, Manuel@roeckx.be, "tls@ietf.org" Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 20:00:59 -0000 On Thu, Mar 13, 2014 at 08:23:45PM +0100, Martin Rex wrote: > I strongly frown upon the idea of resurrecting DH_anon cipher suites > from their cold grave, let alone adding new cruft. > > Generate Server Keys on the fly just like SSH does. Resurrecting > DH_anon turns an initial-leap-of-faith into eternal-leaps-of-faith. You can't do authenticated encryption with SMTP in most of the cases. DANE is currently about the best way to move to authenticated encrypted SMTP, however there are very few sites that bother to set up DNSSEC and DANE. Since it's SMTP is now not authenticated it makes perfect sense to use anonymous DH. The best option for that is currently TLS_DH_anon_WITH_AES_XXX-GCM-SHAXXX, and this would add the ECDH version. I would agree that moving to authenticated encryption would be the best, but since we can't do authenticated encryption we should go for the best thing we can do without authentication, and that would be this proposal. I'm not sure what you mean with your comment about SSH, but I do hope that you actually check the fingerprint of the host you're connecting to. Kurt From nobody Thu Mar 13 14:20:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3891A0778 for ; Thu, 13 Mar 2014 14:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z101e1o0d87H for ; Thu, 13 Mar 2014 14:20:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7981A0496 for ; Thu, 13 Mar 2014 14:20:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 93B26BE5B; Thu, 13 Mar 2014 21:20:43 +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 Ccwk6jNLZWpm; Thu, 13 Mar 2014 21:20:42 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.42.19.100]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6D8E6BE59; Thu, 13 Mar 2014 21:20:42 +0000 (GMT) Message-ID: <5322212A.7050701@cs.tcd.ie> Date: Thu, 13 Mar 2014 21:20:42 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Trevor Perrin References: <531F9443.1000002@cs.tcd.ie> <532080AD.6080907@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gUGcJUUGewixJW5NEPqEzOS7zlg Cc: "tls@ietf.org" Subject: Re: [TLS] TLS chairing changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 21:20:52 -0000 Trevor, On 03/13/2014 07:51 PM, Trevor Perrin wrote: > I assumed at some point after re-chartering we'd discuss process, > timelines, and requirements some more, and have an open process for TLS 1.3 > candidates. Until your email, it wasn't made clear - at least to the list > - that EKR's draft was the presumptive TLS 1.3. I must be crap at writing mail;-) I thought I had said all of: - We will as always have an open process. - "discussing the features and building from those" does not mean that any particular I-D has been adopted by the WG - and as I said, the chairs organise whatever consensus calls are needed (incl. for WG adoption of initial drafts if needed) And lastly (again), maybe wait a week until Sean, Joe and Eric have time to talk before setting the innuendo flying? There really is no need to fuss in the meantime. Thanks, S. From nobody Thu Mar 13 16:01:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113481A0760 for ; Thu, 13 Mar 2014 16:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY1KJDT_nn22 for ; Thu, 13 Mar 2014 16:01:35 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 25A561A058E for ; Thu, 13 Mar 2014 16:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1394751689; x=1426287689; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=tN2DgIxmOMliBssg+KS1fOtSl++vO7+G+UXOPJJi5HQ=; b=Uy+PfqnBG8X825aLmL/nb7+CPTETNzNvpdPJezGDTqV5DCwa9PR1DopN 4+uAe8nmq47ZN3lXG5hsxC+/wR2417Zk+fQ/DZQFOMfbIp9Xz7q+ri9L9 AhFp8vqtVf8ZYjZpQWg7X+wHxZVicCvs2A9lbho3Fey+7ux1SPNo7DJHu 4=; X-IronPort-AV: E=Sophos;i="4.97,649,1389697200"; d="scan'208";a="239570070" 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; 14 Mar 2014 12:01:27 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Fri, 14 Mar 2014 12:01:26 +1300 From: Peter Gutmann To: "" , "ietf-ssh@netbsd.org" Thread-Topic: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx Thread-Index: Ac8/ECkmgTZ4h3K+S8u8HHUPIcV3Hw== Date: Thu, 13 Mar 2014 23:01:26 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C737238B6C3@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XKxTwatcnd2Jy44Hfz4LyVplzeE Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2014 23:01:41 -0000 Alyssa Rowan writes:=0A= =0A= >Can we perhaps make that a SHOULD NOT (or even a MUST NOT), if it somehow= =0A= >isn't already? It's way too common in the wild, and it really is next to= =0A= >useless practice from the same kind of wilful carelessness that brought th= e=0A= >world so many default/engineering/field service passwords/backdoors.=0A= =0A= I doubt it'll make any difference, those who would read and follow the RFC = on=0A= this point won't be using insecure certs/keys anyway, and those who are usi= ng=0A= them will ignore (or not even read to that point) the RFC. I've heard this= =0A= sort of thing referred to in the past as "workgroup posturing", and that's= =0A= unfortunately what it'll be...=0A= =0A= Peter.=0A= From nobody Thu Mar 13 20:13:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC611A086D for ; Thu, 13 Mar 2014 20:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBh20AUnnbnk for ; Thu, 13 Mar 2014 20:13:34 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8851A0700 for ; Thu, 13 Mar 2014 20:13:34 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id c41so1999094yho.39 for ; Thu, 13 Mar 2014 20:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5pE6/hpeWW6eOA1Nvskl95U4A/WmJr985zMy0O54FWo=; b=bRmVgag/ATbRrQLhiGr0plt3lWkKm+fWWY10QSsTwNQ0fU7PwN5Snx1R+XGFYOqe7/ lXZHNAFhcUR7uFODrtuu8Il3IiQVNITKikOOmBQot5MknTRo0rFZ+NrPMDEyG15S1pnI Pb6bMIMCj+rFXEvfpdk3gqoqhSnGFk1d3bcMq/R4wk4yReTxgFn1eZf7SthaoZ1aYbuu bwrE3Lzz94wRJvc2vL2+xZMOAjXzJNi5xaO1YFv7EJSdYDhEKmTXneR71PBj+5kWqGya IjtXSsiw44KtPuz+bOcYRPF58Ly0QVdVD2Wmb33CoK9CXidnZSisvYY9GM2vWX7Dv0uH 4y5w== MIME-Version: 1.0 X-Received: by 10.236.129.36 with SMTP id g24mr7411127yhi.103.1394766807338; Thu, 13 Mar 2014 20:13:27 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Thu, 13 Mar 2014 20:13:27 -0700 (PDT) Date: Thu, 13 Mar 2014 20:13:27 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ni2VbxGDz6olqSiVgi9xMobjKqs Subject: [TLS] TLS and unnecessary complexity X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Mar 2014 03:13:36 -0000 Dear all, TLS is supposed to do three things. 1: Make connections in side of which data is secret, no matter what is sent through them. 2: Let one, both, or none of these sides be authenticated by a public key, plus additional information which TLS doesn't handle or impose restrictions on. 3: Provide information that only the two ends of the connection can possibly know. (SRTP, Channel Binding, etc). TLS 1.2 succeeds only at 1, and only in some configurations. 1,2,and 3 can be achieved with more than ordinary care. TLS 1.0 can't achieve 1, and neither can TLS 1.1. SSL v3 is utterly terrible. In order to fix this you need to deploy all sorts of things not in the RFCs that claim to define TLS, but are rather in extensions. Furthermore, this assumes that both sides actually can reach TLS 1.2. Unnecessary fallbacks are still not fixed. Each implementation is a ball of mud in the usual case: PolarSSL is slightly better. The specification is useful for implementors, but not for auditors: there is no explicit state machine, nor is it easy to determine how particular handshakes work. This is why the security failures of these past few years happened: it was impossible to determine they could not. Even when security issues where known, they were not fixed properly. The complexity of the protocol shows up in the implementations. By contrast a complete implementation of CurveCP fits in fewer pages than RFC 5246 takes to define the language it uses to explain the structures of TLS. The core cryptographic code is 16,000 characters. Purists will object that CurveCP doesn't do authentication, and they are right, but TLS doesn't do any of the TCP functions CurveCP does. Passing an opaque blob to higher levels is probably much shorter than a TCP implementation. This failure mode is not unique to TLS: the Scheme specification is shorter then the index to the Common Lisp specification. However, TLS is inevitably part of every TCB, because of its usefulness and ubiquity. Attempts such as MinimalLT to replace it recognise this and as a result are dead simple. How can TLS 1.3 solve this problem? TLS 1.3 should be described as a state machine that receives and sends messages. The functions used to send and receive messages should be deliberately crippled to force the author to remove complexity as much as possible. This would make it much easier to catch things like the return of renegotiation bugs, as the state machine would have enabled tools like ProVerif to run on it. There is a reason miTLS caught the resumption bug: they were the only people looking with tools powerful enough. No reference should be made to anything beyond the definition of cryptographic transforms. Certificates should be opaque and handed to higher layers, to enable DANE to work on the same basis as X509. Necessary extensions should be documented in the spec itself. All messages should be from regular languages. The current TLS spec fails badly in this respect. This is necessary to write clean, correct, parsing code. Key verification serves the purpose of making cryptographers unhappy. It should be removed. (I can explain at length why this is so) Finally, we should use well-understood primitives in correct manners, and prove that our use is correct. Sincerely, Watson Ladd From nobody Thu Mar 13 22:56:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5999A1A0043; Thu, 13 Mar 2014 22:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 ev6znW8QVzaL; Thu, 13 Mar 2014 22:56:31 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id EBBB61A0040; Thu, 13 Mar 2014 22:56:30 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s2E5tqEk021400; Thu, 13 Mar 2014 22:56:13 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1jkm8rshvs-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Mar 2014 22:56:13 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Thu, 13 Mar 2014 22:56:12 -0700 From: Paul Lambert To: David McGrew , Watson Ladd Date: Thu, 13 Mar 2014 22:56:08 -0700 Thread-Topic: [TLS] [Cfrg] Citing specs in specs Thread-Index: Ac8/ShpmJ0NbR9RRTZ2b/aiqk1wNOg== Message-ID: References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com> <7A2637AF-5A16-404B-B7A1-49FB17D5345A@callas.org> <5317065E.1090007@cisco.com> In-Reply-To: <5317065E.1090007@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-14_03:2014-03-14,2014-03-14,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403130207 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V2Vqu4cDUEWP9T6FbfoAgnj33vY Cc: "cfrg@irtf.org" , Jon Callas , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Fri, 14 Mar 2014 05:56:32 -0000 On 3/5/14, 7:11 PM, "David McGrew" wrote: >On 03/04/2014 12:02 PM, Watson Ladd wrote: >> Dear all, >> This is provisionally my last word on the matter. >> >> Any consensus based process only works if people will block a largely >> formed consensus for a good reason only. A document being unclear, or >> having unanalyzed security properties, or major issues with regards to >> alternatives not being discussed are good reasons. But the argument >> that Paul I think is making, that until the CFRG produces a draft ala >> RFC 6090 for Edwards curve we cannot use them, is fundamentally >> unconvincing. >> >> First off, let me note that black box implementations of Curve25519 >> using the paper are possible: I've written them, Adam Langley has >> written them, as have lots of other people. So that leaves the >> argument that the implementations require too much knowledge about >> cryptography, and that such an issue is worth blocking specs. I was never advocating blocking these specifications. The use of Edwards and Montgomery curves for Internet protocols are relatively new. There are gaps in the documentation of these new mechanisms that should be filled at some point. I was trying to constructively point to worked examples from twenty years of ECC specifications. Paul >> >> The simplest argument for why it is unconvincing is the date of RFC >> 6090 vs. the dates of protocols that included Suite B and ECC. RFC >> 4869 includes Suite B a full 4 years before RFC 6090 was published. >> Now, it is possible that Paul's argument was valid, but simply wasn't >> raised at the time RFC 4869 was being published. But I don't see any >> evidence that implementors of RFC 4869 were hamstrung by the >> nonexistence of RFC 6090. >> >> The second reason I am unconvinced is that I don't see why we >> shouldn't assume the availability of standard references such as the >> Handbook Of Elliptic and Hyperelliptic Curve Cryptography, or volume 2 >> of Knuth, to implementors. Such documents are available for far less >> money than ISO standards, and in many regions of North America, Europe >> and Asia, can be found for free in the library. The goal of a spec is >> to explain to humans what is to be done: including excessive >> information makes this much harder. >> >> Finally, Mr. Lambert writes in terms of the "onus" being on CFRG to >> produce such a document, which he calls a "usable normative >> reference". Such a bare assertion is entirely unconvincing. > > From our charter: "The CFRG serves as a bridge between theory and >practice, bringing new cryptographic techniques to the Internet >community and promoting an understanding of the use and applicability of >these mechanisms via Informational RFCs". We have an opportunity to >promote the understanding, use, and applicability of newer ECC >mechanisms, and I hope that we do so. I woud not say we have the >"onus" to do so, but if CFRG does anything in this area, it should do >what its charter says. > >> Furthermore, CFRG owes Paul nothing. While I would be happy to review >> such a document for accuracy, I have no obligation to review or >> produce such a document, and the same holds for all the members of the >> CFRG. I can just as easily say that Mr. Lambert has the onus to >> produce such a document. >> >> I've changed my mind about the desirability of such a document as Mr. >> Lambert wants. It would be nice if it existed, and it would be a nice >> project to learn CWEB. However, I see no reason to consider the >> absence of such a document a good reason to block >> draft-josefsson-tls-curve25519-04. > >draft-josefsson-tls-curve25519-04 defines a way to use a variant of >Curve25519 in TLS, by describing the differences between RFC4492 >(Weierstrass ECC in TLS) and Curve25519 processing, and some differences >and clarifications relative to the Curve25519 processing described in >the PKC2006 publication. This is clear from the following quotes: > >"Private keys MUST be selected as specified in [Curve25519]. That is, >private keys are 255-bits numbers with the following properties: ..." > >"ECPoint.point differs from the definition of public keys in >[Curve25519] in two ways: ..." > >"Again, in line with [RFC4492] and as a departure from the convention >chosen in [Curve25519], the x coordinate is converted to a byte string >using big endian order. ..." > >"The following subsections describe the differences between using >Curve25519 and the curves defined by RFC 4492 for key exchange in TLS. >... " > >Defining a new thing by its differences from two existing things is not >the best way to get a clear and easy to implement specification. The >authors could improve clarity by brining in more of the description of >Curve25519, or by referencing external work such as an informational >draft/RFC that describes Curve25519 (preferably the same variant as in >draft-josefsson-tls-curve25519). > >One way that RFC6090 added clarity was by clearly separating normative >references from informative ones, and relying only on a small sufficient >set of normative references that were early (pre-1994). It would be >good to have this sort of clarity for IETF work on Curve25519. > >It would be better to have a separate draft/RFC on Curve25519, as >described above, because it will be clearer and more conducive to re-use >of the mechanism across IETF protocols. If no separate normative >document is produced, then it will be important for >draft-josefsson-tls-curve25519 to incorporated a more complete >description of Curve25519. > >Disclaimer: I have not tried to implement >draft-josefsson-tls-curve25519, and I'm not claiming that it is >ambiguous. The authors deserve thanks for writing this document. Our >aim should be to produce clear, well-understood specifications. Not >all RFC are clear or well-understood, but we don't need to emulate that >precedent. > >David > > > >> >> Sincerely, >> Watson Ladd >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > From nobody Thu Mar 13 23:41:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C4C1A005E for ; Thu, 13 Mar 2014 23:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 Lw4ZU97g6hfJ for ; Thu, 13 Mar 2014 23:41:45 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4151F1A0058 for ; Thu, 13 Mar 2014 23:41:45 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 200so5641296ykr.3 for ; Thu, 13 Mar 2014 23:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KeJDKJbh97JxnYvtqJ/jdevqBlEzv3mwKVebMWf5ywM=; b=qk/WLAwBZklYe3Nh7yYMivXVr7BHzN1gxrQdr86gPO67oHk+cmVZlF2rV975JHo5Bu M2/8loxdz/9Oa6fdkKh+nna5tPislI/ximsWkI1pskFrj3Wy2MiUudqq+fmBvOqI5jyH RQi1neEME4E8LJWEjQnr5Wz92gQTConSwVqamjUbNSduK98tlYQTXxPBA1syp6GsOi0Z Z0dfNpDKUauoE9c4Q4379p2RtpUlabnJ4iaCS9Medo3vf3WEWeL5EJFMD2jG8VLaLwgt reB59NVfJ7nz7g71Jq17sbN8QUN/5Hbwkxt+ivCU35U0Mx0ncTbX8SML5DVvwdQtBzK2 AivA== MIME-Version: 1.0 X-Received: by 10.236.131.163 with SMTP id m23mr8191169yhi.61.1394779298439; Thu, 13 Mar 2014 23:41:38 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Thu, 13 Mar 2014 23:41:38 -0700 (PDT) In-Reply-To: References: <530FDC7A.4060404@cisco.com> <5310B12E.4070603@cisco.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com> <7A2637AF-5A16-404B-B7A1-49FB17D5345A@callas.org> <5317065E.1090007@cisco.com> Date: Thu, 13 Mar 2014 23:41:38 -0700 Message-ID: From: Watson Ladd To: Paul Lambert Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2kYEVHAPZW2xytRUI7kf7Teg1kw Cc: "cfrg@irtf.org" , Jon Callas , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Citing specs in 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: Fri, 14 Mar 2014 06:41:48 -0000 On Thu, Mar 13, 2014 at 10:56 PM, Paul Lambert wrote: > > > On 3/5/14, 7:11 PM, "David McGrew" wrote: > >>On 03/04/2014 12:02 PM, Watson Ladd wrote: >>> Dear all, >>> This is provisionally my last word on the matter. >>> >>> Any consensus based process only works if people will block a largely >>> formed consensus for a good reason only. A document being unclear, or >>> having unanalyzed security properties, or major issues with regards to >>> alternatives not being discussed are good reasons. But the argument >>> that Paul I think is making, that until the CFRG produces a draft ala >>> RFC 6090 for Edwards curve we cannot use them, is fundamentally >>> unconvincing. >>> >>> First off, let me note that black box implementations of Curve25519 >>> using the paper are possible: I've written them, Adam Langley has >>> written them, as have lots of other people. So that leaves the >>> argument that the implementations require too much knowledge about >>> cryptography, and that such an issue is worth blocking specs. > > I was never advocating blocking these specifications. I have to apologise: I misread your initial email as saying that the Curve25519 was an insufficient normative reference as meaning that it didn't define things clearly enough, and therefore you thought the spec was ambiguous. I realise now you meant that, independent of the citation issue, you wanted more documentation. > > The use of Edwards and Montgomery curves for Internet protocols are > relatively new. There are gaps in the documentation of these new > mechanisms that should be filled at some point. I was trying to > constructively point to worked examples from twenty years of ECC > specifications. And that is currently being worked on by Robert Ransom, who seems to have taken over right now from myself. I'll probably jump in this weekend and write up the algorithms that are required to compute point multiples, together with the precautions to avoid side channels. The big problem with Edwards is we don't have a good point format yet. Robert Ransom has a good idea, but I haven't seen explicit formulas for encoding and decoding yet. Sincerely, Watson Ladd > > Paul > >>> >>> The simplest argument for why it is unconvincing is the date of RFC >>> 6090 vs. the dates of protocols that included Suite B and ECC. RFC >>> 4869 includes Suite B a full 4 years before RFC 6090 was published. >>> Now, it is possible that Paul's argument was valid, but simply wasn't >>> raised at the time RFC 4869 was being published. But I don't see any >>> evidence that implementors of RFC 4869 were hamstrung by the >>> nonexistence of RFC 6090. >>> >>> The second reason I am unconvinced is that I don't see why we >>> shouldn't assume the availability of standard references such as the >>> Handbook Of Elliptic and Hyperelliptic Curve Cryptography, or volume 2 >>> of Knuth, to implementors. Such documents are available for far less >>> money than ISO standards, and in many regions of North America, Europe >>> and Asia, can be found for free in the library. The goal of a spec is >>> to explain to humans what is to be done: including excessive >>> information makes this much harder. >>> >>> Finally, Mr. Lambert writes in terms of the "onus" being on CFRG to >>> produce such a document, which he calls a "usable normative >>> reference". Such a bare assertion is entirely unconvincing. >> >> From our charter: "The CFRG serves as a bridge between theory and >>practice, bringing new cryptographic techniques to the Internet >>community and promoting an understanding of the use and applicability of >>these mechanisms via Informational RFCs". We have an opportunity to >>promote the understanding, use, and applicability of newer ECC >>mechanisms, and I hope that we do so. I woud not say we have the >>"onus" to do so, but if CFRG does anything in this area, it should do >>what its charter says. >> >>> Furthermore, CFRG owes Paul nothing. While I would be happy to review >>> such a document for accuracy, I have no obligation to review or >>> produce such a document, and the same holds for all the members of the >>> CFRG. I can just as easily say that Mr. Lambert has the onus to >>> produce such a document. >>> >>> I've changed my mind about the desirability of such a document as Mr. >>> Lambert wants. It would be nice if it existed, and it would be a nice >>> project to learn CWEB. However, I see no reason to consider the >>> absence of such a document a good reason to block >>> draft-josefsson-tls-curve25519-04. >> >>draft-josefsson-tls-curve25519-04 defines a way to use a variant of >>Curve25519 in TLS, by describing the differences between RFC4492 >>(Weierstrass ECC in TLS) and Curve25519 processing, and some differences >>and clarifications relative to the Curve25519 processing described in >>the PKC2006 publication. This is clear from the following quotes: >> >>"Private keys MUST be selected as specified in [Curve25519]. That is, >>private keys are 255-bits numbers with the following properties: ..." >> >>"ECPoint.point differs from the definition of public keys in >>[Curve25519] in two ways: ..." >> >>"Again, in line with [RFC4492] and as a departure from the convention >>chosen in [Curve25519], the x coordinate is converted to a byte string >>using big endian order. ..." >> >>"The following subsections describe the differences between using >>Curve25519 and the curves defined by RFC 4492 for key exchange in TLS. >>... " >> >>Defining a new thing by its differences from two existing things is not >>the best way to get a clear and easy to implement specification. The >>authors could improve clarity by brining in more of the description of >>Curve25519, or by referencing external work such as an informational >>draft/RFC that describes Curve25519 (preferably the same variant as in >>draft-josefsson-tls-curve25519). >> >>One way that RFC6090 added clarity was by clearly separating normative >>references from informative ones, and relying only on a small sufficient >>set of normative references that were early (pre-1994). It would be >>good to have this sort of clarity for IETF work on Curve25519. >> >>It would be better to have a separate draft/RFC on Curve25519, as >>described above, because it will be clearer and more conducive to re-use >>of the mechanism across IETF protocols. If no separate normative >>document is produced, then it will be important for >>draft-josefsson-tls-curve25519 to incorporated a more complete >>description of Curve25519. >> >>Disclaimer: I have not tried to implement >>draft-josefsson-tls-curve25519, and I'm not claiming that it is >>ambiguous. The authors deserve thanks for writing this document. Our >>aim should be to produce clear, well-understood specifications. Not >>all RFC are clear or well-understood, but we don't need to emulate that >>precedent. >> >>David >> >> >> >>> >>> Sincerely, >>> Watson Ladd >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Mar 14 09:07:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B363C1A0161 for ; Fri, 14 Mar 2014 09:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 5iHToXPoJvmF for ; Fri, 14 Mar 2014 09:07:15 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 16F9F1A015B for ; Fri, 14 Mar 2014 09:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=133; q=dns/txt; s=iport; t=1394813228; x=1396022828; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=wvjZAATJCK0D4XOP+hNiRawCCKJMpozeRcSmjDE0RF8=; b=dA6YpPS0oITRKp9MEUgFNCSNKJtZyHS1tL8GuYs/GPI3MJfSe1vwxT0S bH+J4v2eNwugftKLeM08xreMU5AaUqPdHO0C71DB2ouFIj51Dullo2B3k PNB1ADNQkQWHcuwLLaKfKmTS+oQoStghJTvRk35VlwbpgF2DlHOBdvR5n g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFANInI1OtJV2d/2dsb2JhbABZgwY7GT7DChZ0giw6UQE+QicEHIdwDaIcsVQXkhKBFASYRZIugy2CKw X-IronPort-AV: E=Sophos;i="4.97,655,1389744000"; d="scan'208";a="310389124" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 14 Mar 2014 16:07:08 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2EG78Vm012153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Mar 2014 16:07:08 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.247]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Fri, 14 Mar 2014 11:07:07 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Draft meeting minutes from IETF 89 Thread-Index: AQHPP59yda+AER2YwUK44Kd1NFCRDg== Date: Fri, 14 Mar 2014 16:07:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.67] Content-Type: text/plain; charset="us-ascii" Content-ID: <591B154B3B473F4F95784D3EB282A0D8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CiDYAfAjcAcyvfRiKnITL-fu34I Subject: [TLS] Draft meeting minutes from IETF 89 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Mar 2014 16:07:17 -0000 Draft meeting minutes from IETF 89 are available at: http://www.ietf.org/proceedings/89/minutes/minutes-89-tls Cheers, Joe From nobody Fri Mar 14 14:04:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D5C1A01EF for ; Fri, 14 Mar 2014 14:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUJUG5MT64-4 for ; Fri, 14 Mar 2014 14:04:28 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 67C201A01CB for ; Fri, 14 Mar 2014 14:04:28 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s2EL4IJM028714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Mar 2014 22:04:19 +0100 (MET) In-Reply-To: To: Andrei Popov Date: Fri, 14 Mar 2014 22:04:18 +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: <20140314210418.CEE5A1AC53@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uz3AKqVcK1-_FjT39H2mKArXfGA Cc: "tls@ietf.org" , "draft-ietf-tls-applayerprotoneg@tools.ietf.org" Subject: Re: [TLS] Mentioning DTLS 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, 14 Mar 2014 21:04:39 -0000 Andrei Popov wrote: > > Mentioning DTLS makes sense; I have no objection to making this > change in the next revision. Speaking of DTLS. NEITHER of the two official DTLS specifications of the IETF does support TLS extensions. There exists no definition of a TLS ClientHello PDU that provides room for (D)TLS extensions, and there is no forward extensibility notice for the DTLS ClientHello PDU in the fashion that was retrofitted into the SSLv3 specification. If DTLS was supposed to allow TLS extensions in the DTLS ClientHello PDU, then someone (preferably a DTLS implementor or one of the document authors) really should file erratas with a description of the DTLS ExtendendedClientHello and DTLS ExtendedServerHello PDUs for both DTLS specifications (rfc4347 and rfc6347). -Martin From nobody Fri Mar 14 14:10:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E191A01DE for ; Fri, 14 Mar 2014 14:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxd4KqSb-0H9 for ; Fri, 14 Mar 2014 14:10:08 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 783251A01CB for ; Fri, 14 Mar 2014 14:10:08 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so2585818wes.37 for ; Fri, 14 Mar 2014 14:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K4GKKzj2SuPgZ/ToMQ5wGXcjNY4YS728Ewxnz2wQcXE=; b=mcdTxSnn1wtVy5ucEYFPuRodJahwhW8DMp2c6QZ0HqtjKE+x+39hMjUsunI81xD4R5 +dbnqYLGpoIXZHXlOV3vhEh01AAk2U1/SrPZQMYQgk5ZsAUz76cEsUOiKIzYi2fHCxP2 9pP8i+ayC64M72NuQ1rUtxpFm2fx2fxItY4uMnTznVMSohDhMalCDj1DAJV78KISACQK acMc7pyGt5WkDU2ILEUr38urpUJuo5mlIq1P18pb2gLTwWJ25lB+7vrAB8X8Vwz+HKb6 9jahachRheUbHcBTZAyRnMZ1gAwEdty4Bi1YEOSlH/d8uVoAJQVpPb3O9or8zA6ZPMwr /5WA== MIME-Version: 1.0 X-Received: by 10.180.75.202 with SMTP id e10mr49637wiw.50.1394831401128; Fri, 14 Mar 2014 14:10:01 -0700 (PDT) Received: by 10.227.10.196 with HTTP; Fri, 14 Mar 2014 14:10:01 -0700 (PDT) In-Reply-To: <20140314210418.CEE5A1AC53@ld9781.wdf.sap.corp> References: <20140314210418.CEE5A1AC53@ld9781.wdf.sap.corp> Date: Fri, 14 Mar 2014 14:10:01 -0700 Message-ID: From: Martin Thomson To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_hdMsqxmeBwFJcdunV14dRo7AGE Cc: "tls@ietf.org" , "draft-ietf-tls-applayerprotoneg@tools.ietf.org" Subject: Re: [TLS] Mentioning DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Mar 2014 21:10:10 -0000 On 14 March 2014 14:04, Martin Rex wrote: > NEITHER of the two official DTLS specifications of the IETF does support > TLS extensions. I don't know how you came to that conclusion. The definition of ClientHello is inherited from the corresponding TLS specification, isn't it? From nobody Fri Mar 14 15:07:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A331A01F4 for ; Fri, 14 Mar 2014 15:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 bjfEhc9xrfgR for ; Fri, 14 Mar 2014 15:07:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 9F59E1A01EC for ; Fri, 14 Mar 2014 15:07:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AA0EA7FC179; Fri, 14 Mar 2014 15:06:55 -0700 (PDT) To: ekr@rtfm.com, nagendra@cs.stanford.edu, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, jsalowey@cisco.com, ekr@rtfm.com From: RFC Errata System Message-Id: <20140314220655.AA0EA7FC179@rfc-editor.org> Date: Fri, 14 Mar 2014 15:06:55 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pQc39NBolyFkHkWdkppMOvC3s4Q Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Technical Errata Reported] RFC6347 (3917) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Mar 2014 22:07:05 -0000 The following errata report has been submitted for RFC6347, "Datagram Transport Layer Security Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6347&eid=3917 -------------------------------------- Type: Technical Reported by: Martin Thomson Section: 4.2.1 Original Text ------------- struct { ProtocolVersion client_version; Random random; SessionID session_id; opaque cookie<0..2^8-1>; // New field CipherSuite cipher_suites<2..2^16-1>; CompressionMethod compression_methods<1..2^8-1>; } ClientHello; Corrected Text -------------- struct { ProtocolVersion client_version; Random random; SessionID session_id; opaque cookie<0..2^8-1>; // New field CipherSuite cipher_suites<2..2^16-1>; CompressionMethod compression_methods<1..2^8-1>; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ClientHello; Notes ----- This also affects Section 4.3.2 where the same structure is repeated. Extensions are a part of TLS. They are also part of DTLS in practice, but the RFC omits them. The corrected text includes the relevant part of the ClientHello from RFC 5246. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6347 (draft-ietf-tls-rfc4347-bis-06) -------------------------------------- Title : Datagram Transport Layer Security Version 1.2 Publication Date : January 2012 Author(s) : E. Rescorla, N. Modadugu Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Mar 14 15:11:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39861A01FC for ; Fri, 14 Mar 2014 15:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0icTZQWIWjx9 for ; Fri, 14 Mar 2014 15:11:41 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 01C491A0206 for ; Fri, 14 Mar 2014 15:11:40 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so130809wiv.7 for ; Fri, 14 Mar 2014 15:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yFDNXAh7xyU+9KQuSS/K/H2vJLpXbBTe1WFL2q2Iy/s=; b=iLsmRWgNJXKZmxwVrJf6JLzOFs6iweYNFg2+uXH8TUMXfmCUPcAHJvH99u+tSoj1ut TR0sqOytox+kXAXZOlwZSovpyZV4m3IuQK8MXZwslyF9PMfGLmWgQC0aiw7Da677OAmn ioCmBUeCJSAlM7y3LvwdWaoKaMVS7SyaNfCG5TKr1FkyYJJYhSRMYAUdLMHYDXxDaIlI 5cLQt1A4WBGp8jvLkQwGvH2jyCqC6t7PMwJzIOkFpvJay0WK3Zo/heYb4TvhoIxso3lQ 5geOGQKJOJ0+gVxoyuAHR/WvQTsBZGX9WxQWpzg70WjtIslVqyj1AapoPZnx05J+yQrr HLDA== MIME-Version: 1.0 X-Received: by 10.180.84.73 with SMTP id w9mr218625wiy.58.1394835093625; Fri, 14 Mar 2014 15:11:33 -0700 (PDT) Received: by 10.227.10.196 with HTTP; Fri, 14 Mar 2014 15:11:33 -0700 (PDT) In-Reply-To: References: <20140314210418.CEE5A1AC53@ld9781.wdf.sap.corp> Date: Fri, 14 Mar 2014 15:11:33 -0700 Message-ID: From: Martin Thomson To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/csQaM4wNXIP48BRWubOZjM_dwWM Cc: "tls@ietf.org" , "draft-ietf-tls-applayerprotoneg@tools.ietf.org" Subject: Re: [TLS] Mentioning DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Mar 2014 22:11:43 -0000 On 14 March 2014 14:10, Martin Thomson wrote: > On 14 March 2014 14:04, Martin Rex wrote: >> NEITHER of the two official DTLS specifications of the IETF does support >> TLS extensions. > > I don't know how you came to that conclusion. The definition of > ClientHello is inherited from the corresponding TLS specification, > isn't it? I see what the problem is now. It looks like 6347 and co have opted to omit the extensions. Most implementations I know of support extension, even though this was omitted. Erratum on 6347 filed (4347 is obsolete, so I'm not going to bother with it). http://www.rfc-editor.org/errata_search.php?rfc=6347&eid=3917 From nobody Fri Mar 14 15:25:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7CA1A0208 for ; Fri, 14 Mar 2014 15:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4gyduP23m4P for ; Fri, 14 Mar 2014 15:25:49 -0700 (PDT) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id E7E351A014F for ; Fri, 14 Mar 2014 15:25:48 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so2631272wes.20 for ; Fri, 14 Mar 2014 15:25:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YIWrMxLywN6pKM7x7Z3NyFQ78FyGDm85SFiHnvbb8S4=; b=KdiZCySwQLK3UYieNGUSsbvRgrbtpmwFeCBa/OwyBrNOiJD6JY/r7hbcWobNJr2Mfq JsXagXDAJpTzgRGfydp93Wyy5j67rmA0t/EmvIREgZnanPJaENvBJa/83QwD3cMy6WKV 7+DS7UtQ9bAD7LJR0vSEDIAU4c10E1zr22lkshiOxTLRZv8GaJ6mhepewpQjvZE14BWc XEQs2/9ZUNpgns8DrHkUEOf4Rum2OpwVUy2kHChwzschxiDU47hyCPL9QFNFEBzVOawt uM2jpPXafVXgva6vjToj83QPbOctTjcWxd5/zLYCRlvTO/L7/cI0HgxbxcWhLvbm0dwt 4wCw== X-Gm-Message-State: ALoCoQlQvv7TGZW6x+KHe3FamTz5KYywpBiEzbjAjiFCNZ4nEtFl1DXehbCYyBMr58X9MP03B8kT X-Received: by 10.194.2.70 with SMTP id 6mr8651009wjs.25.1394835941403; Fri, 14 Mar 2014 15:25:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Fri, 14 Mar 2014 15:25:01 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <20140314210418.CEE5A1AC53@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Fri, 14 Mar 2014 15:25:01 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b3a8174cec76e04f4988c11 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/poPfTfYUSxAkVgZwSiXCsWh3wdg Cc: "tls@ietf.org" , "draft-ietf-tls-applayerprotoneg@tools.ietf.org" Subject: Re: [TLS] Mentioning DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Mar 2014 22:25:51 -0000 --047d7b3a8174cec76e04f4988c11 Content-Type: text/plain; charset=ISO-8859-1 Martin R, thanks for pointing this out. Good catch. Martin T, thanks for the errata! -Ekr On Fri, Mar 14, 2014 at 3:11 PM, Martin Thomson wrote: > On 14 March 2014 14:10, Martin Thomson wrote: > > On 14 March 2014 14:04, Martin Rex wrote: > >> NEITHER of the two official DTLS specifications of the IETF does support > >> TLS extensions. > > > > I don't know how you came to that conclusion. The definition of > > ClientHello is inherited from the corresponding TLS specification, > > isn't it? > > I see what the problem is now. It looks like 6347 and co have opted > to omit the extensions. Most implementations I know of support > extension, even though this was omitted. Erratum on 6347 filed (4347 > is obsolete, so I'm not going to bother with it). > > http://www.rfc-editor.org/errata_search.php?rfc=6347&eid=3917 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7b3a8174cec76e04f4988c11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Martin R, thanks for pointing this out. Good catch.
Martin T, thanks for the errata!

-Ekr=



On Fri, Mar 14, 2014 at 3:11 PM, Martin Thomson <martin.thomson@gma= il.com> wrote:
On 14 March 2014 14:10, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 14 March 2014 14:04, Martin Rex <mrex@sap.com> wrote:
>> NEITHER of the two official DTLS specifications of the IETF does s= upport
>> TLS extensions.
>
> I don't know how you came to that conclusion. =A0The definition of=
> ClientHello is inherited from the corresponding TLS specification,
> isn't it?

I see what the problem is now. =A0It looks like 6347 and co have opte= d
to omit the extensions. =A0Most implementations I know of support
extension, even though this was omitted. =A0Erratum on 6347 filed (4347
is obsolete, so I'm not going to bother with it).

http://www.rfc-editor.org/errata_search.php?rfc= =3D6347&eid=3D3917

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

--047d7b3a8174cec76e04f4988c11-- From nobody Sat Mar 15 17:47:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462901A02B0 for ; Sat, 15 Mar 2014 17:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRcmsRSZh8rW for ; Sat, 15 Mar 2014 17:47:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EEAED1A02AE for ; Sat, 15 Mar 2014 17:47:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2D560BEE1; Sun, 16 Mar 2014 00:47:33 +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 q55wtpzoKqcn; Sun, 16 Mar 2014 00:47:31 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.46.25.186]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A95E8BEDC; Sun, 16 Mar 2014 00:47:31 +0000 (GMT) Message-ID: <5324F4A3.7030800@cs.tcd.ie> Date: Sun, 16 Mar 2014 00:47:31 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Eric Rescorla , Martin Thomson References: <20140314210418.CEE5A1AC53@ld9781.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SjDP9oKb8gU0yPI_TADUmpU1vmk Cc: "tls@ietf.org" , "draft-ietf-tls-applayerprotoneg@tools.ietf.org" Subject: Re: [TLS] Mentioning DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Mar 2014 00:47:45 -0000 So assuming nobody finds a problem with the erratum (and I remember;-) I'll mark it approved in a day or so. S On 03/14/2014 10:25 PM, Eric Rescorla wrote: > Martin R, thanks for pointing this out. Good catch. > > Martin T, thanks for the errata! > > -Ekr > > > > On Fri, Mar 14, 2014 at 3:11 PM, Martin Thomson wrote: > >> On 14 March 2014 14:10, Martin Thomson wrote: >>> On 14 March 2014 14:04, Martin Rex wrote: >>>> NEITHER of the two official DTLS specifications of the IETF does support >>>> TLS extensions. >>> >>> I don't know how you came to that conclusion. The definition of >>> ClientHello is inherited from the corresponding TLS specification, >>> isn't it? >> >> I see what the problem is now. It looks like 6347 and co have opted >> to omit the extensions. Most implementations I know of support >> extension, even though this was omitted. Erratum on 6347 filed (4347 >> is obsolete, so I'm not going to bother with it). >> >> http://www.rfc-editor.org/errata_search.php?rfc=6347&eid=3917 >> >> _______________________________________________ >> 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 nobody Sun Mar 16 10:21:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD3F1A02F2 for ; Sun, 16 Mar 2014 10:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amxUQ5TTzEBr for ; Sun, 16 Mar 2014 10:21:48 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id F0FE21A01D5 for ; Sun, 16 Mar 2014 10:21:47 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id e49so3278635eek.31 for ; Sun, 16 Mar 2014 10:21:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=NaSXI2tof8o8luKDyAk2BqfbbBHcOYPt4HWhgzaWptY=; b=SNbT4ciRdx2QqgeEqbUP6/hYNrG1fjUCW7aqmzAzpnHnlcv4lRmvPbOj7N24iAv39S l60VguKcKsQLXOt1Ke8hztiYVMzaOtyVAWBoBWopyAdgAteiP3U6bj7xAPItp2dmg8/s uYRu0Mpu9M+Dd5MX8+xM6BpJCOepxwvOOgqbXgiH2HisUroOidUYJH7bW6fAdgBWmgcB aGcIK95OTBC57ja75PJZhzLGyIUU3+Nct8WtlF1MH2HxNMqAnPh6O1wSZuufUokEZAQo BfWBmow2blrUBUG2QnSz+4xTuGsrxq487LMhDSYZ7WoEMsioi4ukQFp6gC1pEmsERcGV mpXQ== X-Gm-Message-State: ALoCoQnjhskZg3ufaX3g4Zm+QPNCCXTRHFHr1Azk32VmT0o84Y5mQc1OmgDS8D8v5TWMg8ZD0zjk X-Received: by 10.14.193.201 with SMTP id k49mr19332830een.50.1394990499910; Sun, 16 Mar 2014 10:21:39 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id j41sm33473236eeg.10.2014.03.16.10.21.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Mar 2014 10:21:39 -0700 (PDT) Message-ID: <5325DDA0.9030006@nthpermutation.com> Date: Sun, 16 Mar 2014 13:21:36 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tzzXlnRCznqx4iVrGQ-sqhJbqF8 Subject: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 17:21:50 -0000 During the TLS meeting EKR talked about encrypting most of the protocol negotiation, and noted that the primary use case for that was the SNI. Someone else noted, that the SNI was often used as routing information by distributor boxes and might be problematic to encrypt. Further discussion ensued (http://www.ietf.org/proceedings/89/minutes/minutes-89-tls) leading to a hum on protecting the SNI that was pretty much down the center of do/don't. After thinking about it for a bit - how about simply hashing the data in the SNI? Ideally calculated with a prefix of a random value that's also sent along in the SNI so the same hash isn't sent over and over? struct { opaque tag[8]; opaque hash<16,24,32, etc>; /* hashed name of the host being connected to */ } HashedSNI; The middle distributor box would need to be told which names it was forwarding, but only that. It would calculate hashes using the concatenation of the tag and the names it knows, and compare the hash value to the hash in the HashedSNI to figure out the forwarding. This is not "perfect security" by any means, but provides a bit of on-the-wire privacy. The attacker would have to know the set of names at that IP address to determine which name was being contacted. It does have the virtue that it doesn't require shared keys between either the client and server, or between the server and middle box. Mike From nobody Sun Mar 16 10:44:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8293F1A0167 for ; Sun, 16 Mar 2014 10:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W7Jf-_eLXWd for ; Sun, 16 Mar 2014 10:44:18 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5069E1A0165 for ; Sun, 16 Mar 2014 10:44:18 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id e49so3289700eek.17 for ; Sun, 16 Mar 2014 10:44:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lhLxXaPMu4L3Ly+o74loZ1jsKDriiP/ZR48q+ATirAc=; b=aGwrnWcrbwVbg2KR4VB4qkID0/CXdy1A9+s0G7HFcOMA2diYhu9wVy/2n/vsofiDE/ 4NHWlQYk/JntaeaIbfvbniJ8P7VaRMLWRnzOAxxePDxIaDOUD9TZeIeqDZEJOu/5U7PN 8X2jn1ME5pxlw0G29H7pACT0RQNwJ7eNIv2n2yqMPDpI/yThLH0I5YRomR4erlUx5sQA 7elgqtVREGlj3WeJU7Rm1xpYzcAPc8upWoNS6mJ8T6JcSXENh1Bvfi+iCnT4e+jjRLEK nFnWTk9EQWYMkES+LOa2p7e5L5R+RUDGsdyz5iW7NN8Y67vdoMJlL4KWa0zinyT9NAUM LamA== X-Gm-Message-State: ALoCoQm+uijuYj1c3lb55S9/04VXtyFcUYSHXPXdA95TfXIs0KJs04orv/P7OMxJHMbaxvMwMhf2 X-Received: by 10.14.102.71 with SMTP id c47mr19407331eeg.19.1394991850315; Sun, 16 Mar 2014 10:44:10 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id s46sm33625937ees.3.2014.03.16.10.44.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Mar 2014 10:44:09 -0700 (PDT) Message-ID: <5325E2E7.2090702@nthpermutation.com> Date: Sun, 16 Mar 2014 13:44:07 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <20140314210418.CEE5A1AC53@ld9781.wdf.sap.corp> <5324F4A3.7030800@cs.tcd.ie> In-Reply-To: <5324F4A3.7030800@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_3O7WwxuXTfz9G6EKqkmA54zzAI Subject: Re: [TLS] Mentioning DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Mar 2014 17:44:20 -0000 On 3/15/2014 8:47 PM, Stephen Farrell wrote: > So assuming nobody finds a problem with the erratum > (and I remember;-) I'll mark it approved in a day or > so. > > S While this is a valid errata submission, reading https://www.ietf.org/iesg/statement/errata-processing.html - guideline 7 suggests that since this was present all the way back in 2006 and not fixed in this version, what the IESG is going to do is mark it as Hold for Document Update. And we really should be implementing what's been written down, rather than writing down what's been implemented - at least for RFCs! Mike > > On 03/14/2014 10:25 PM, Eric Rescorla wrote: >> Martin R, thanks for pointing this out. Good catch. >> >> Martin T, thanks for the errata! >> >> -Ekr >> >> >> >> On Fri, Mar 14, 2014 at 3:11 PM, Martin Thomson wrote: >> >>> On 14 March 2014 14:10, Martin Thomson wrote: >>>> On 14 March 2014 14:04, Martin Rex wrote: >>>>> NEITHER of the two official DTLS specifications of the IETF does support >>>>> TLS extensions. >>>> I don't know how you came to that conclusion. The definition of >>>> ClientHello is inherited from the corresponding TLS specification, >>>> isn't it? >>> I see what the problem is now. It looks like 6347 and co have opted >>> to omit the extensions. Most implementations I know of support >>> extension, even though this was omitted. Erratum on 6347 filed (4347 >>> is obsolete, so I'm not going to bother with it). >>> >>> http://www.rfc-editor.org/errata_search.php?rfc=6347&eid=3917 >>> >>> _______________________________________________ >>> 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 nobody Sun Mar 16 11:12:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC2C1A02A6 for ; Sun, 16 Mar 2014 11:12:42 -0700 (PDT) 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, J_CHICKENPOX_46=0.6, LOTS_OF_MONEY=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 NGvbuWk6MBCs for ; Sun, 16 Mar 2014 11:12:41 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 761111A0167 for ; Sun, 16 Mar 2014 11:12:41 -0700 (PDT) Received: by mail-yk0-f175.google.com with SMTP id 131so12604689ykp.6 for ; Sun, 16 Mar 2014 11:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M1S/5pKrA1+Q5RkfxHNRKK+JV5bi6qC0pecYCdtINKU=; b=fartvGGRhZlEx04d+uuJv1VcK2T+Ka1heCusa9maqD76249WhIV68osu9PtwQpG4HD 260uuYrbTGQeUKObyZw/6IhFu5fJlQY4PlzNE/6BTIpdREvOrJ3imw992u6pjUStIac+ UY3ufBF8hgaCgm5V0Mm6z6CjhYGek7TG0cFZRGLrlmZknCGie9ixSQ3orL0FRB96RQBA FbEJIeqCh6+DXtnI7fuHRKWCBTWp11+jz3kV5/xtmHuk2eAV1fEaPHzlbZ7zjOfq3IP7 1m99RgeiAeg4OY7791AEvzo1lgbdT3bXhAAGyjCUtfCCAzcjeOWb2Gyznz3BOKwwb/ue /ZAA== MIME-Version: 1.0 X-Received: by 10.236.191.67 with SMTP id f43mr27308440yhn.60.1394993553736; Sun, 16 Mar 2014 11:12:33 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Sun, 16 Mar 2014 11:12:33 -0700 (PDT) In-Reply-To: <5325DDA0.9030006@nthpermutation.com> References: <5325DDA0.9030006@nthpermutation.com> Date: Sun, 16 Mar 2014 11:12:33 -0700 Message-ID: From: Watson Ladd To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/E6TuQ-e75kWx1fxN-sncFBDrwyQ Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 18:12:43 -0000 On Sun, Mar 16, 2014 at 10:21 AM, Michael StJohns wrote: > During the TLS meeting EKR talked about encrypting most of the protocol > negotiation, and noted that the primary use case for that was the SNI. > Someone else noted, that the SNI was often used as routing information by > distributor boxes and might be problematic to encrypt. Further discussion > ensued (http://www.ietf.org/proceedings/89/minutes/minutes-89-tls) leading > to a hum on protecting the SNI that was pretty much down the center of > do/don't. > > After thinking about it for a bit - how about simply hashing the data in the > SNI? Ideally calculated with a prefix of a random value that's also sent > along in the SNI so the same hash isn't sent over and over? >From time to time, people have a privacy issue like NSEC. Someone comes along and says "I know! we'll use hashing." and we get NSEC3. Do you know how many SHA256 calls per second off-the-shelf commercial ASICs can do? It's about 155 million per second per dollar. Do you know how many hostnames there are? Well, theoretically many, but most are made human-readable: the entropy is much lower than the length and alphabet would suggest. The attacker can determine which name is being contacted with a few weeks of calculation. Once it has the hostnames, figuring out what is going on is quick. This already exists in the form of the nsec3walker tool. Sincerely, Watson Ladd From nobody Sun Mar 16 11:21:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C1E1A0167 for ; Sun, 16 Mar 2014 11:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKdkVHbDZzTM for ; Sun, 16 Mar 2014 11:21:44 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EACD51A017E for ; Sun, 16 Mar 2014 11:21:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 10E5EBEC6; Sun, 16 Mar 2014 18:21:35 +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 uUoFiqSAIhKe; Sun, 16 Mar 2014 18:21:33 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.42.22.156]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B6779BEBF; Sun, 16 Mar 2014 18:21:33 +0000 (GMT) Message-ID: <5325EBAD.5030303@cs.tcd.ie> Date: Sun, 16 Mar 2014 18:21:33 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael StJohns , tls@ietf.org References: <20140314210418.CEE5A1AC53@ld9781.wdf.sap.corp> <5324F4A3.7030800@cs.tcd.ie> <5325E2E7.2090702@nthpermutation.com> In-Reply-To: <5325E2E7.2090702@nthpermutation.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_jdyhz9Zw6exkC0NMARWW48JKW0 Subject: Re: [TLS] Mentioning DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Mar 2014 18:21:47 -0000 On 03/16/2014 05:44 PM, Michael StJohns wrote: > On 3/15/2014 8:47 PM, Stephen Farrell wrote: >> So assuming nobody finds a problem with the erratum >> (and I remember;-) I'll mark it approved in a day or >> so. >> >> S > > While this is a valid errata submission, reading > https://www.ietf.org/iesg/statement/errata-processing.html - guideline 7 > suggests > that since this was present all the way back in 2006 and not fixed in > this version, what the IESG is going to do is mark it as Hold for > Document Update. And we really should be implementing what's been > written down, rather than writing down what's been implemented - at > least for RFCs! I'll take that as someone claiming there's a problem then and wait on the chairs to tell me what they figure the WG consensus is on processing this. S. > > Mike > > >> >> On 03/14/2014 10:25 PM, Eric Rescorla wrote: >>> Martin R, thanks for pointing this out. Good catch. >>> >>> Martin T, thanks for the errata! >>> >>> -Ekr >>> >>> >>> >>> On Fri, Mar 14, 2014 at 3:11 PM, Martin Thomson >>> wrote: >>> >>>> On 14 March 2014 14:10, Martin Thomson >>>> wrote: >>>>> On 14 March 2014 14:04, Martin Rex wrote: >>>>>> NEITHER of the two official DTLS specifications of the IETF does >>>>>> support >>>>>> TLS extensions. >>>>> I don't know how you came to that conclusion. The definition of >>>>> ClientHello is inherited from the corresponding TLS specification, >>>>> isn't it? >>>> I see what the problem is now. It looks like 6347 and co have opted >>>> to omit the extensions. Most implementations I know of support >>>> extension, even though this was omitted. Erratum on 6347 filed (4347 >>>> is obsolete, so I'm not going to bother with it). >>>> >>>> http://www.rfc-editor.org/errata_search.php?rfc=6347&eid=3917 >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From nobody Sun Mar 16 12:42:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEBB1A0223 for ; Sun, 16 Mar 2014 12:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, LOTS_OF_MONEY=0.001, 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 Wn9Fwn5fYSrv for ; Sun, 16 Mar 2014 12:42:01 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 64D061A018A for ; Sun, 16 Mar 2014 12:42:01 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so3915176wgh.5 for ; Sun, 16 Mar 2014 12:41:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jUtY/Uyezt0OJESsvh2ZOwaLy3PYuHLf13GchJ1Ayvw=; b=LeB7S+t+vybD2ztr3ymrVmg4LkasblnCHJ8+n4hgdFywroIiEN+dlL0jud3h7y5cwC s/r0RlP6dpk0lFVurBXbrM7krmvW+uGaj9U1dSKyPYli3IE3G/lv/wCTVToa096K9vNB DCS2K6ySN6msb1tKol6plFs3StGKIAdcZGdTbzVFb6Pzf1sNxN0+Jggu9oKZf0+cA8kl Avd358qTNLAMwozktHT8rZX1gpGxmcpxYeTKBNk5QPH48CZtjNHs4eM76y6SU79QShmB Vk9l/CWdILXxN42Ie+3hE/uFWo2R4XrTAybay85LEzSzpZW1A4hsHBfWv2uUSeA+LVo+ uWFg== X-Gm-Message-State: ALoCoQlQoyg/m+oK3Uj4ES5cr2zjkOc7A/mgOKTzwphwkUtiRg7/uaPH9eY1sbIjt5LEx3yU5w+d X-Received: by 10.180.164.229 with SMTP id yt5mr6578885wib.49.1394998913102; Sun, 16 Mar 2014 12:41:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sun, 16 Mar 2014 12:41:12 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <5325DDA0.9030006@nthpermutation.com> From: Eric Rescorla Date: Sun, 16 Mar 2014 12:41:12 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=00248c11e82dad964504f4be7e16 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MmQeGkBz10vaQ5HJJzRGjIBw3dg Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 19:42:03 -0000 --00248c11e82dad964504f4be7e16 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 16, 2014 at 11:12 AM, Watson Ladd wrote: > On Sun, Mar 16, 2014 at 10:21 AM, Michael StJohns > wrote: > > During the TLS meeting EKR talked about encrypting most of the protocol > > negotiation, and noted that the primary use case for that was the SNI. > > Someone else noted, that the SNI was often used as routing information by > > distributor boxes and might be problematic to encrypt. Further > discussion > > ensued (http://www.ietf.org/proceedings/89/minutes/minutes-89-tls) > leading > > to a hum on protecting the SNI that was pretty much down the center of > > do/don't. > > > > After thinking about it for a bit - how about simply hashing the data in > the > > SNI? Ideally calculated with a prefix of a random value that's also sent > > along in the SNI so the same hash isn't sent over and over? > > >From time to time, people have a privacy issue like NSEC. Someone > comes along and says > "I know! we'll use hashing." and we get NSEC3. > > Do you know how many SHA256 calls per second off-the-shelf commercial > ASICs can do? It's about 155 million per second per dollar. > > Do you know how many hostnames there are? Well, theoretically many, > but most are made human-readable: the entropy is much lower than the > length and alphabet would suggest. > > The attacker can determine which name is being contacted with a few > weeks of calculation. Once it has the hostnames, > figuring out what is going on is quick. This already exists in the > form of the nsec3walker tool. > Good point. If anything, this analysis is too pessimistic. In the most common case, the attacker will have some idea of the set of SNIs being served by a given server, e.g., because TLS 1.2 SNIs are in the clear. At that point, as you note above, the problem of determining which of the small set of SNIs is being used is much easier. -Ekr Sincerely, > Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00248c11e82dad964504f4be7e16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Mar 16, 2014 at 11:12 AM, Watson Ladd <= ;watsonbladd@gma= il.com> wrote:
On Sun, Mar 16, 2014 at 10:2= 1 AM, Michael StJohns
<msj@nthpermutation.com>= ; wrote:
> During the TLS meeting EKR talked about encrypting most of the protoco= l
> negotiation, and noted that the primary use case for that was the SNI.=
> Someone else noted, that the SNI was often used as routing information= by
> distributor boxes and might be problematic to encrypt. =A0Further disc= ussion
> ensued (http://www.ietf.org/proceedings/89/minutes/minute= s-89-tls) leading
> to a hum on protecting the SNI that was pretty much down the center of=
> do/don't.
>
> After thinking about it for a bit - how about simply hashing the data = in the
> SNI? Ideally calculated with a prefix of a random value that's als= o sent
> along in the SNI so the same hash isn't sent over and over?

>From time to time, people have a privacy issue like NSEC. Someone=
comes along and says
"I know! we'll use hashing." and we get NSEC3.

Do you know how many SHA256 calls per second off-the-shelf commercial
ASICs can do? It's about 155 million per second per dollar.

Do you know how many hostnames there are? Well, theoretically many,
but most are made human-readable: the entropy is much lower than the
length and alphabet would suggest.

The attacker can determine which name is being contacted with a few
weeks of calculation. Once it has the hostnames,
figuring out what is going on is quick. This already exists in the
form of the nsec3walker tool.

Good poin= t.

If anything, this analysis is too pessimistic. = In the most common case, the
attacker will have some idea of the = set of SNIs being served by a given
server, e.g., because TLS 1.2 SNIs are in the clear. At that point, as= you
note above, the problem of determining which of the small se= t of SNIs
is being used is much easier.

-Ekr



Sincerely,
Watson Ladd

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

--00248c11e82dad964504f4be7e16-- From nobody Sun Mar 16 13:09:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A807F1A0314 for ; Sun, 16 Mar 2014 13:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, 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 ZUCcQB8QS26h for ; Sun, 16 Mar 2014 13:08:58 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE171A0311 for ; Sun, 16 Mar 2014 13:08:57 -0700 (PDT) Received: from [192.168.1.200] (p508F0E91.dip0.t-ipconnect.de [80.143.14.145]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id CE4CF1C0ACD58; Sun, 16 Mar 2014 21:08:47 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <5325E2E7.2090702@nthpermutation.com> Date: Sun, 16 Mar 2014 21:08:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7757C3BA-89E3-4932-82A9-3F22610E7153@lurchi.franken.de> References: <20140314210418.CEE5A1AC53@ld9781.wdf.sap.corp> <5324F4A3.7030800@cs.tcd.ie> <5325E2E7.2090702@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4Bq8OvhJIa0iVmhP0EwMwcptgSU Cc: tls@ietf.org Subject: Re: [TLS] Mentioning DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Mar 2014 20:09:00 -0000 On 16 Mar 2014, at 18:44, Michael StJohns = wrote: > On 3/15/2014 8:47 PM, Stephen Farrell wrote: >> So assuming nobody finds a problem with the erratum >> (and I remember;-) I'll mark it approved in a day or >> so. >>=20 >> S >=20 > While this is a valid errata submission, reading = https://www.ietf.org/iesg/statement/errata-processing.html - guideline 7 = suggests > that since this was present all the way back in 2006 and not fixed in = this version, what the IESG is going to do is mark it as Hold for = Document Update. And we really should be implementing what's been = written down, rather than writing down what's been implemented - at = least for RFCs! Hi Mike, please note that there are also RFCs specifying DTLS extensions. See http://tools.ietf.org/html/rfc6520 So I think this is really an errata, as Martin Thomson pointed out. Best regards Michael >=20 > Mike >=20 >=20 >>=20 >> On 03/14/2014 10:25 PM, Eric Rescorla wrote: >>> Martin R, thanks for pointing this out. Good catch. >>>=20 >>> Martin T, thanks for the errata! >>>=20 >>> -Ekr >>>=20 >>>=20 >>>=20 >>> On Fri, Mar 14, 2014 at 3:11 PM, Martin Thomson = wrote: >>>=20 >>>> On 14 March 2014 14:10, Martin Thomson = wrote: >>>>> On 14 March 2014 14:04, Martin Rex wrote: >>>>>> NEITHER of the two official DTLS specifications of the IETF does = support >>>>>> TLS extensions. >>>>> I don't know how you came to that conclusion. The definition of >>>>> ClientHello is inherited from the corresponding TLS specification, >>>>> isn't it? >>>> I see what the problem is now. It looks like 6347 and co have = opted >>>> to omit the extensions. Most implementations I know of support >>>> extension, even though this was omitted. Erratum on 6347 filed = (4347 >>>> is obsolete, so I'm not going to bother with it). >>>>=20 >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6347&eid=3D3917 >>>>=20 >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >>=20 >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Sun Mar 16 13:28:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06ED1A0311 for ; Sun, 16 Mar 2014 13:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JY8xpxHDa2n5 for ; Sun, 16 Mar 2014 13:28:18 -0700 (PDT) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id ABEF61A01F9 for ; Sun, 16 Mar 2014 13:28:17 -0700 (PDT) Received: by mail-ee0-f45.google.com with SMTP id d17so3420465eek.32 for ; Sun, 16 Mar 2014 13:28:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/amHFfTWeD0Yqgauz6FmqmJGgTqmt6os/xbRZnsNO4k=; b=li5Q4PfKMXeL4oHmwSTFBnrYlJn9tGqbCS+zZfuh3T3tCLEoRiamyuNjhtN9DjGUDp ZhBz5fem6O47Z5jp5pLVZbN8maY+7+yNQWDawRubqdQXG5P5FGpoxThR7CBxVRRbFeNm ks0wnodBPWBaIQ3CgmWQBdl/6F7BcM0+Fz+l2km7hyC60PNf6eboTcHBeTCT8I3jwCEV 1bBJ5F0SWXqxsEacKZkkZMof3Wxs+dWmT+01EBECpEPXPhYQRtZehlzbbAHzFdz244uk eTLpIWrsjq9P+aUb6rjRaDIjxc15lMPfWV/P/DV98VSawVgN13JomkeKT3TwgyCkSuag ewRg== X-Gm-Message-State: ALoCoQmGQSi69qvdPaZCIWA/n+Geui76HfHo3TLMuiLsuTJyQPjXKxhMxLswSnxQZW5pfALYAiCd X-Received: by 10.15.53.135 with SMTP id r7mr1028082eew.102.1395001689590; Sun, 16 Mar 2014 13:28:09 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id j41sm34547106eeg.10.2014.03.16.13.28.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Mar 2014 13:28:08 -0700 (PDT) Message-ID: <53260956.8080709@nthpermutation.com> Date: Sun, 16 Mar 2014 16:28:06 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Farrell , tls@ietf.org References: <20140314210418.CEE5A1AC53@ld9781.wdf.sap.corp> <5324F4A3.7030800@cs.tcd.ie> <5325E2E7.2090702@nthpermutation.com> <5325EBAD.5030303@cs.tcd.ie> In-Reply-To: <5325EBAD.5030303@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9PUt1CKvmWqpND7GrPgNIA6pp0c Subject: Re: [TLS] Mentioning DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Mar 2014 20:28:20 -0000 On 3/16/2014 2:21 PM, Stephen Farrell wrote: > > On 03/16/2014 05:44 PM, Michael StJohns wrote: >> On 3/15/2014 8:47 PM, Stephen Farrell wrote: >>> So assuming nobody finds a problem with the erratum >>> (and I remember;-) I'll mark it approved in a day or >>> so. >>> >>> S >> While this is a valid errata submission, reading >> https://www.ietf.org/iesg/statement/errata-processing.html - guideline 7 >> suggests >> that since this was present all the way back in 2006 and not fixed in >> this version, what the IESG is going to do is mark it as Hold for >> Document Update. And we really should be implementing what's been >> written down, rather than writing down what's been implemented - at >> least for RFCs! > I'll take that as someone claiming there's a problem then > and wait on the chairs to tell me what they figure the WG > consensus is on processing this. Hi Stephen - Wasn't objecting, just pointing out that the IESG may end up requiring an RFC to fix this and that we should be prepared for that. Later, Mike > > S. > > >> Mike >> >> >>> On 03/14/2014 10:25 PM, Eric Rescorla wrote: >>>> Martin R, thanks for pointing this out. Good catch. >>>> >>>> Martin T, thanks for the errata! >>>> >>>> -Ekr >>>> >>>> >>>> >>>> On Fri, Mar 14, 2014 at 3:11 PM, Martin Thomson >>>> wrote: >>>> >>>>> On 14 March 2014 14:10, Martin Thomson >>>>> wrote: >>>>>> On 14 March 2014 14:04, Martin Rex wrote: >>>>>>> NEITHER of the two official DTLS specifications of the IETF does >>>>>>> support >>>>>>> TLS extensions. >>>>>> I don't know how you came to that conclusion. The definition of >>>>>> ClientHello is inherited from the corresponding TLS specification, >>>>>> isn't it? >>>>> I see what the problem is now. It looks like 6347 and co have opted >>>>> to omit the extensions. Most implementations I know of support >>>>> extension, even though this was omitted. Erratum on 6347 filed (4347 >>>>> is obsolete, so I'm not going to bother with it). >>>>> >>>>> http://www.rfc-editor.org/errata_search.php?rfc=6347&eid=3917 >>>>> >>>>> _______________________________________________ >>>>> TLS mailing list >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > From nobody Sun Mar 16 13:29:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CA51A0311 for ; Sun, 16 Mar 2014 13:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTJnip2fJmYk for ; Sun, 16 Mar 2014 13:29:36 -0700 (PDT) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 154F21A01F9 for ; Sun, 16 Mar 2014 13:29:35 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id b15so3368580eek.6 for ; Sun, 16 Mar 2014 13:29:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2iVg0k1obfFvM78SMBpmMxkWkp9VWgFa65IAPdnAuRk=; b=h3hCz5QsYMUZvdwankOUTu9/sZv7JmsGGCGFNMDuN+Q2jCZS9vh236/E7iqtD8QPGQ tswJ2DOs+HX+MrJkv6yrWENjzq5MlkJMduAjA1UKN6P6AHeNwa7T3CxnkPq9cays2vEF 9FWM3D1GHOadXCUdcPjiFHxZMCo6f2h//snPIG8rU/EDMZOwfkfyhbNkRatQ5WfINOmD mjpyrctPhNtQ+TVl2Dgls1/B/qqd+dboCAZkh4vuVuHzwcrv0/AmWro42q5EqHP/4hZh 9I4ipspkqW+DDL567D8nhb22bUAsqUdor7YyZKb2Ns+OzUvVShKF7Jz8EbnHgEwD/E2l /cjw== X-Gm-Message-State: ALoCoQl20pMMZdHltwKiLJfCSLQvLTLp/KQpGGURK0ChSaGF2otjM1jJLbyAje0j3px1yp4nv8f9 X-Received: by 10.14.207.68 with SMTP id m44mr4435960eeo.79.1395001767978; Sun, 16 Mar 2014 13:29:27 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id 43sm34546022eeh.13.2014.03.16.13.29.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Mar 2014 13:29:27 -0700 (PDT) Message-ID: <532609A4.40800@nthpermutation.com> Date: Sun, 16 Mar 2014 16:29:24 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Tuexen References: <20140314210418.CEE5A1AC53@ld9781.wdf.sap.corp> <5324F4A3.7030800@cs.tcd.ie> <5325E2E7.2090702@nthpermutation.com> <7757C3BA-89E3-4932-82A9-3F22610E7153@lurchi.franken.de> In-Reply-To: <7757C3BA-89E3-4932-82A9-3F22610E7153@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OMnx5cp9H6P2CppfbYz-kIP9Yx8 Cc: tls@ietf.org Subject: Re: [TLS] Mentioning DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Mar 2014 20:29:38 -0000 On 3/16/2014 4:08 PM, Michael Tuexen wrote: > On 16 Mar 2014, at 18:44, Michael StJohns wrote: > >> On 3/15/2014 8:47 PM, Stephen Farrell wrote: >>> So assuming nobody finds a problem with the erratum >>> (and I remember;-) I'll mark it approved in a day or >>> so. >>> >>> S >> While this is a valid errata submission, reading https://www.ietf.org/iesg/statement/errata-processing.html - guideline 7 suggests >> that since this was present all the way back in 2006 and not fixed in this version, what the IESG is going to do is mark it as Hold for Document Update. And we really should be implementing what's been written down, rather than writing down what's been implemented - at least for RFCs! > Hi Mike, > > please note that there are also RFCs specifying DTLS extensions. See > http://tools.ietf.org/html/rfc6520 > So I think this is really an errata, as Martin Thomson pointed out. It is an errata - but the handling of errata has three outputs, only one of which is "We heard it, you're good to go" :-) But your point is taken, and that fact should be included in the errata justification. > > Best regards > Michael >> Mike >> >> >>> On 03/14/2014 10:25 PM, Eric Rescorla wrote: >>>> Martin R, thanks for pointing this out. Good catch. >>>> >>>> Martin T, thanks for the errata! >>>> >>>> -Ekr >>>> >>>> >>>> >>>> On Fri, Mar 14, 2014 at 3:11 PM, Martin Thomson wrote: >>>> >>>>> On 14 March 2014 14:10, Martin Thomson wrote: >>>>>> On 14 March 2014 14:04, Martin Rex wrote: >>>>>>> NEITHER of the two official DTLS specifications of the IETF does support >>>>>>> TLS extensions. >>>>>> I don't know how you came to that conclusion. The definition of >>>>>> ClientHello is inherited from the corresponding TLS specification, >>>>>> isn't it? >>>>> I see what the problem is now. It looks like 6347 and co have opted >>>>> to omit the extensions. Most implementations I know of support >>>>> extension, even though this was omitted. Erratum on 6347 filed (4347 >>>>> is obsolete, so I'm not going to bother with it). >>>>> >>>>> http://www.rfc-editor.org/errata_search.php?rfc=6347&eid=3917 >>>>> >>>>> _______________________________________________ >>>>> TLS mailing list >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > From nobody Sun Mar 16 13:41:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CC81A01F9 for ; Sun, 16 Mar 2014 13:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6, 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 o1iR1YW8HGrV for ; Sun, 16 Mar 2014 13:41:01 -0700 (PDT) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id 150B51A0310 for ; Sun, 16 Mar 2014 13:41:00 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c13so3417251eek.38 for ; Sun, 16 Mar 2014 13:40:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5DjgRzcXajuBsSnXi4fb3kaA/aJBiW0wAb/lqOTiAK0=; b=ciyOs1ey2ATQTvWyzkEowVVVLq2yhrS+K1/x5jULqmeb+f3MlQemSBjbiiNxx2di1Y kz+EKNYwcrvXyoFESifxj0RC6GACPMRhE3sVsWJhxJVzBO8YAcun/XdXFx7KPZDGnQJF PYE/j3gaOjfkflF0kc8W8ZmuruX+MUI4gN497c7fHUUOL2pPnUosDuin1qXIlE5N1L11 mAfdC27+U2lfCRBcqb9BpY42jscFhcr8rSTtaC7f3caxNstXPHkigWvPUlwWsqGGU44c Xe/DGWYC8SgTkKq2Z6PUsGhPITm20KT6xSn0aOQ5HomfErZ8ZOoBVwWRamkLsV/UALbQ b+ng== X-Gm-Message-State: ALoCoQmihDj4mJv9CbPB+hi+gYMKiFODiSt8Jz9vnxx5tjE1pnQKDHMObwkyfoO9u9Gmny0TXz1S X-Received: by 10.14.4.201 with SMTP id 49mr20144963eej.13.1395002452809; Sun, 16 Mar 2014 13:40:52 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id 44sm22312886eek.30.2014.03.16.13.40.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Mar 2014 13:40:52 -0700 (PDT) Message-ID: <53260C51.10407@nthpermutation.com> Date: Sun, 16 Mar 2014 16:40:49 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Watson Ladd References: <5325DDA0.9030006@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sEQBX4o6ZF2-gqTjXhgl6Q7f7K4 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 20:41:04 -0000 On 3/16/2014 2:12 PM, Watson Ladd wrote: > On Sun, Mar 16, 2014 at 10:21 AM, Michael StJohns > wrote: >> During the TLS meeting EKR talked about encrypting most of the protocol >> negotiation, and noted that the primary use case for that was the SNI. >> Someone else noted, that the SNI was often used as routing information by >> distributor boxes and might be problematic to encrypt. Further discussion >> ensued (http://www.ietf.org/proceedings/89/minutes/minutes-89-tls) leading >> to a hum on protecting the SNI that was pretty much down the center of >> do/don't. >> >> After thinking about it for a bit - how about simply hashing the data in the >> SNI? Ideally calculated with a prefix of a random value that's also sent >> along in the SNI so the same hash isn't sent over and over? > >From time to time, people have a privacy issue like NSEC. Someone > comes along and says > "I know! we'll use hashing." and we get NSEC3. NSEC3 was not a privacy issue item, it was a database walking item. > > Do you know how many SHA256 calls per second off-the-shelf commercial > ASICs can do? It's about 155 million per second per dollar. Ok - let's inject a little bit of financial analysis. Two questions: 1) What's the cost of making the first attack (not the delta, but the minimum cost to an attacker to build something to do what you're talking about, PLUS the cost of actually acquiring the data on the wire)? 2) What's the value of the first piece of data to the specific attacker? My point is that unless there is specific value to the attacker, and that value is greater than the cost to the attacker of making the attack, then the attack won't happen. Two further questions: 3) What, exactly, is the value of the privacy of the query data to the querier and how much does that value degrade over time once the query has been made? 4) Just how much can be spent on protection before the protection costs exceed the value of the data? and two further questions. 5) Are the anticipated attacks general (shot gun) or targeted? 6) If targeted, does encryption provide sufficient protection or could the data be gotten for similar costs via other attacks? It was clear from the WG meeting that there wasn't consensus to add encryption across the board - whether from a disagreement on need or whether the mechanism EKR proposed was the way to go or possibly something else. That said, if this is about trying to protect against well funded attackers, encryption in not a panacea. If this is about a casual eavesdropper, then maybe a simpler solution is reasonable. > > Do you know how many hostnames there are? Well, theoretically many, > but most are made human-readable: the entropy is much lower than the > length and alphabet would suggest. > > The attacker can determine which name is being contacted with a few > weeks of calculation. Weeks? Oh - you're worried about a shotgun and national actor approach, rather than the typical attacker. OK. In any event, there are any number of ways to increase an attackers work factor substantially without increasing the work factor for someone that already knows the small set of answers. Think of it as a DNS arms race and we win if we make them spend more than they get back in value. You used 155m hashes per dollar - so if we increase the work factor to say 500m hashes to find a name, then it costs $3 per query to resolve to the names. How many connections per day are there? Later, Mike > Once it has the hostnames, > figuring out what is going on is quick. This already exists in the > form of the nsec3walker tool. > > Sincerely, > Watson Ladd > > From nobody Sun Mar 16 14:31:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C201A031A for ; Sun, 16 Mar 2014 14:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=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 0N0Fkdr_kNej for ; Sun, 16 Mar 2014 14:31:12 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 39EC31A0314 for ; Sun, 16 Mar 2014 14:31:12 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id if17so4861662vcb.36 for ; Sun, 16 Mar 2014 14:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7VhwjX2kJJ4qJ0ojud1qt7kY8HDfTU6D3is7vtB0BzE=; b=nxkehPrFcHqSX4gSlXTSxEicQDiX11UVYajBcctU+j5BLyXZExfZMm/UNpfwogAGIT 1tEN/3fb9P7WFKYWZyy7axG1SOqft+XpvELuQSsNH22XheQ3YL36WCiwxnOPMwRkIa6u 3nlH0p3VD078ZmGs76soOqkUPEuFoWdPvnYA3oxMLzuYxxeZE/hpJQJETG6QaEWg0N1v vW/jThJ1vOt5Qy4wEIMy/AjZ83+6LE5Cz1asiS1Ga1s4/bHw4Ybbv+nBUgzg/Y7YimZP AFnkOJYFIA7lODDgS1i+EqV947OLhii8YF0b6qx2H7uo2+iw0GxCHITPF4E+QnunYd/C aB6A== MIME-Version: 1.0 X-Received: by 10.58.122.164 with SMTP id lt4mr16993079veb.2.1395005464342; Sun, 16 Mar 2014 14:31:04 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.220.91.132 with HTTP; Sun, 16 Mar 2014 14:31:04 -0700 (PDT) In-Reply-To: <53260C51.10407@nthpermutation.com> References: <5325DDA0.9030006@nthpermutation.com> <53260C51.10407@nthpermutation.com> Date: Sun, 16 Mar 2014 17:31:04 -0400 X-Google-Sender-Auth: dacdqD7s36_3vvKRSK9HzJbbxRc Message-ID: From: Erik Nygren To: Michael StJohns Content-Type: multipart/alternative; boundary=047d7b2ed2552977ae04f4c00562 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/U79L0pvyGUcCsdbU3WiQxLLZka0 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 21:31:13 -0000 --047d7b2ed2552977ae04f4c00562 Content-Type: text/plain; charset=ISO-8859-1 It's unclear how much harder it makes this for the anti-privacy attacker, but it certainly makes it easier for attackers trying to attack a middle distributor/demuxer box. Pros helping the passive anti-privacy attacker: they also have server IP address to constrain the problem space by, plus TLS 1.2 SNIs so if there are a 100k hostnames behind the middlebox then that's their search space. Pros helping the DDoS attacker: they can just send random hash+opaque values. The middle box needs to then calculate the hash for all of the hostnames (eg, perhaps 100k in the same scenario above). As such, it is actually cheaper for the anti-privacy attacker than it is for the middle/demuxer box to handle this traffic under a DDoS scenario and about the same cost (but still quite expensive!) under normal traffic flows. This likely incentives the middle/demux operator to use more IPs to help protect themselves which also makes life easier for the attacker (and chews up IPv4 space). Erik --047d7b2ed2552977ae04f4c00562 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It's unclear how much harder it makes t= his for the anti-privacy attacker, but it certainly makes it easier for att= ackers trying to attack a middle distributor/demuxer box.

Pros= helping the passive anti-privacy attacker:=A0 they also have server IP add= ress to constrain the problem space by, plus TLS 1.2 SNIs so if there are a= 100k hostnames behind the middlebox then that's their search space.
Pros helping the DDoS attacker: they can just send random hash+opaque v= alues.=A0 The middle box needs to then calculate the hash for all of the ho= stnames (eg, perhaps 100k in the same scenario above).

As such= , it is actually cheaper for the anti-privacy attacker than it is for the m= iddle/demuxer box to handle this traffic under a DDoS scenario and about th= e same cost (but still quite expensive!) under normal traffic flows.=A0 Thi= s likely incentives the middle/demux operator to use more IPs to help prote= ct themselves which also makes life easier for the attacker (and chews up I= Pv4 space).

=A0=A0=A0=A0=A0=A0=A0=A0=A0 Erik

--047d7b2ed2552977ae04f4c00562-- From nobody Sun Mar 16 16:47:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A801A0210 for ; Sun, 16 Mar 2014 16:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=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 Ewt5sXRGAPkL for ; Sun, 16 Mar 2014 16:47:31 -0700 (PDT) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBE01A020B for ; Sun, 16 Mar 2014 16:47:31 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id c41so3507594eek.36 for ; Sun, 16 Mar 2014 16:47:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Yv7iKYmqmdDQmSEOmcLAF/NKCBLnW793Cl/lon/lE+A=; b=IKKQOgQzoG3Y0TE72OBGfZBrIdMGo/zWk5afvMV7F0RtkQ0qbiN5LB1KJ24MfQrgDX W9jlyjNFUjjPeVZaAdeRJVLuOjb9I7+5WYAObhoZHWerS7xHLLAEueRmE2NlIi44wLRK Uw2lcYMN1OgFxPrqzs0kLuTs7Eouy8vlGq1krt+MKi1FF7dmQOJDUDiQHTPbsXOHmKkj 46gZZs1kI8VJFpJwSP633g42flsRbRGCEgrHClDLzlxL7HIi+JZ/Wbvmv91D/b2SNLWk UL8p/12/rx/iK0fd+rGKveBaIC9TdV9DpKb75n91KnI8JzTn80QS6ROy2+kDn6SVQXNd rh2g== X-Gm-Message-State: ALoCoQloTGVy43+j4xL4Q99xe/OlAxyyzHm29dNG0tW2tJ5WG8OAcWdtYcJGRUaMxtwBQC2NVLP7 X-Received: by 10.15.32.206 with SMTP id a54mr20228153eev.51.1395013643222; Sun, 16 Mar 2014 16:47:23 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id 46sm35582166ees.4.2014.03.16.16.47.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Mar 2014 16:47:22 -0700 (PDT) Message-ID: <53263807.9020005@nthpermutation.com> Date: Sun, 16 Mar 2014 19:47:19 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Erik Nygren References: <5325DDA0.9030006@nthpermutation.com> <53260C51.10407@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vOLzNJJ7lww7PL_E0j1PU39uerU Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 23:47:33 -0000 On 3/16/2014 5:31 PM, Erik Nygren wrote: > Pros helping the passive anti-privacy attacker: they also have server > IP address to constrain the problem space by, plus TLS 1.2 SNIs so if > there are a 100k hostnames behind the middlebox then that's their > search space. > > Pros helping the DDoS attacker: they can just send random hash+opaque > values. The middle box needs to then calculate the hash for all of > the hostnames (eg, perhaps 100k in the same scenario above). I don't disagree with any of your points (but there's always a tradeoff between DOS protections and negotiation protections), but I wanted to focus on the 100K. The question is - if the SNI is encrypted from the client to the end system, how do the end systems communicate with the middle box to pass on their key info and keep it up to date - not on a per-box 100K basis, but on a 100K times the number of connections per box? I think what we're getting to is that if we have a system where there is a middle box, then neither of these approaches makes a lot of sense for the scale you're talking about? Mike From nobody Sun Mar 16 18:43:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0C11A0356 for ; Sun, 16 Mar 2014 18:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SXBtIAlvb7kP for ; Sun, 16 Mar 2014 18:43:45 -0700 (PDT) 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 49F281A0352 for ; Sun, 16 Mar 2014 18:43:45 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id fp1so4911229pdb.14 for ; Sun, 16 Mar 2014 18:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rbo0GVXrWWnJ2t9u4I4fHvUYMjA0k1A2uzQeRKQJB8Y=; b=fLOeaiNeEx/kQNjfNuVk4VvKLN98ZT6BQcYkevY0VP7PEIyA1yn//h/80o9eJTsWtg hWifN3ezmu2Z6jf9UiMwTHgRoM2PHNr3VBYzBahNBDjGQ6/MXQA+jJCht8mK1LornS72 5M/7T0N6Pi6bVFxeCbD/VmYWXbBAqwkWJb0n8= 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=rbo0GVXrWWnJ2t9u4I4fHvUYMjA0k1A2uzQeRKQJB8Y=; b=jTK2HdSmFf1qjMWxqkQvIOjE5W4JKxDmWuQ2MDpMy/BvTLWFWnPh+RNayyVQGVQO/P 9gXBm4DwT2eN/BFDwXvtnKoXIq0CvQxCnzXbBAhmXiMWr2yVaDxccb+trrFXmyEv0J4U O21BU6swqAJRhLOx9cvQsZ87x978F8Mea104rkF/8AToo5PLx+UKVsmrQI6xOoNBNIyz TGTJ177VXA7sAntiX4q7Y9u7OhPLqJoq734DDsBDVIpNWvPVQ3YEvHN/U4jEtM5hodaC o/AFa6udqOwARXPGbrjOSIqE9+m/HQNgyq1Uq7gL1A/aKwwnJ/t442cgbNi+Ixrt18xj LO9g== X-Gm-Message-State: ALoCoQmbJY3OpGJsbAeRf/mKTUGRZHihwUXFZb5rEjXtXO5WG0ZvmZzuo4Us+N3ZATyluv2ZHYV2 X-Received: by 10.68.96.99 with SMTP id dr3mr22843341pbb.40.1395020617633; Sun, 16 Mar 2014 18:43:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.198.68 with HTTP; Sun, 16 Mar 2014 18:43:17 -0700 (PDT) In-Reply-To: <5325DDA0.9030006@nthpermutation.com> References: <5325DDA0.9030006@nthpermutation.com> From: Tom Ritter Date: Sun, 16 Mar 2014 18:43:17 -0700 Message-ID: To: Michael StJohns Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RcCDUCwnrRPQ_q46qNPR0TvJdDs Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 01:43:46 -0000 On 16 March 2014 10:21, Michael StJohns wrote: > During the TLS meeting EKR talked about encrypting most of the protocol > negotiation, and noted that the primary use case for that was the SNI. What about protecting the certificate sent by the server? What about protecting supported ciphersuites and extensions listed - taking steps towards protecting what user agent is being used? What about client certificates - protecting identity of the client? What about extensions? SRP Data, Client/Server Auth data, Padding? If we had this before, the DHE exchange would be protected and we wouldn't be exposing 1024 DH all over the place. If we spend all our time focusing on trying to protect individual components, we'll find arguments against any of them. I'd much rather start from the perspective of protecting everything and address problems on an individual basis. When building a cryptographic protocol you don't choose the smallest security margin you can think of for the application. -tom From nobody Sun Mar 16 21:23:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973FC1A0381 for ; Sun, 16 Mar 2014 21:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTCPtDxoN2It for ; Sun, 16 Mar 2014 21:23:25 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) by ietfa.amsl.com (Postfix) with ESMTP id 27C441A0380 for ; Sun, 16 Mar 2014 21:23:25 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id q200so13724911ykb.8 for ; Sun, 16 Mar 2014 21:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zNd537/NeSjbsWfiZWia/9txWGvYCatiAlB3Q8mS+wo=; b=tOEmeZsP3BYvc0r7TqfKpotfgfL1jQwYArr0LN4Ec4VDKGbobH8FqGggmHyIk5epGZ tCP//+Sw+sSwRNZA2ystyFjXbtwjZQ/5NNtYd7kwS1kZLF4+hBi7M50kF/+J7ZUl2LCu EdTxyCP3uAcaRb9eza7pNSHrG5uvG60XKbya/T2YpuOPNWXHwKXywhchwDoscSYeQ9Ai 9MoE7iQ6SeE2002nWcii72Hu/Oxkmih22zbL4AFsk8hAi01VPIWJ8dUU82HPs21Mlyu8 6iLPHQWPbsbhMQm8dzTL58clqiIitPjAFV5vVqGwYAXaOALUPs77kKmzkOl8VyGc/UHJ SnTQ== MIME-Version: 1.0 X-Received: by 10.236.126.162 with SMTP id b22mr7128149yhi.72.1395030197319; Sun, 16 Mar 2014 21:23:17 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Sun, 16 Mar 2014 21:23:17 -0700 (PDT) In-Reply-To: <53260C51.10407@nthpermutation.com> References: <5325DDA0.9030006@nthpermutation.com> <53260C51.10407@nthpermutation.com> Date: Sun, 16 Mar 2014 21:23:17 -0700 Message-ID: From: Watson Ladd To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GkijV9ZRUokfVmudH468ObbOPUM Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 04:23:26 -0000 Dear Mr. StJohns, Suppose you work at the Chinese Ministry of Truth, in the department of web truthmaking, domain forgetting division. Right now, if you want to ensure HTTP content is in conformance with the truth you simply scan for the Host header and check against a list. For HTTPS life could get nasty. But luckily we decided to put SNI information on the outside, so you can see if that connection needs to go down the memory hole. Now you hear about this TLS 1.3 coming along, and how it obfuscates SNI. So you present the following design to your boss: 1: Each device on the filtering maintains a global IP->[Hosts] mapping. 2: When an obfuscated SNI comes along, you check against all hosts in the mapping 3: If it is marked as untruthful block 4: If unknown, transmit it to a dedicated cracking machine. Within a week the cracking machine is likely to figure out what the hostname is, at which point it can be added to the list. If the agents watching the spreading of untruth see a domain, we can just add it. The computational cost will never exceed that of the hosting device. Your proposal doesn't stop censorship or even make it more expensive. It doesn't hide visits to websites effectively if the attacker is interested in checking against a big list. It doesn't accomplish any of the goals we need it to. Sincerely, Watson Ladd From nobody Mon Mar 17 00:31:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D8B1A006E for ; Mon, 17 Mar 2014 00:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id el1gyEEP86le for ; Mon, 17 Mar 2014 00:31:49 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 699DD1A0270 for ; Mon, 17 Mar 2014 00:31:49 -0700 (PDT) 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 C85616015C for ; Mon, 17 Mar 2014 07:31:40 +0000 (GMT) Message-ID: <5326A478.1090907@akr.io> Date: Mon, 17 Mar 2014 07:30:00 +0000 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <5325DDA0.9030006@nthpermutation.com> In-Reply-To: <5325DDA0.9030006@nthpermutation.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hq9sNkY0DWjotKErWdD1YNvFa70 Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 07:31:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 16/03/2014 17:21, Michael StJohns wrote: > The middle distributor box would ...have access to the keys if it's really owned by the same party. Otherwise we're back to passive pervasive surveillance/censorship. SNI needs to be _encrypted_ and we need to make sure that encryption is resistant to matching against known-plaintext due to DNS lookups and TLS 1.2 SNI currently being in cleartext (having not switched to encrypted yet). - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTJqR4AAoJEOyEjtkWi2t6nOwP/1yUsK3v+E6Paha8BTloygRG 9I5tfYvzjy05ZHiEFmESoWlpopM/MqJMXyD81jWXt8bpn2SwQrmzru3TmCbDENse jVy5G26EwQfx4G8Njkg9dzHMR2pQVKLZUKg9B9N5vqGkWnlHiubSJSTZuNKx9XHi DPLYyXw/UYA2Ys99BVPLLhH95DfNAUQQkkkThFQB8+9aQA80alIUcYb7mr/tflTf Zt+IOvIgcx5vDDBI8uqfi+MDlMLSxsNzQ16AzolFzQSYXqPwJ9vZJ4/cfde92y/I Z8gUwhcEQGzCcXh7rx0ZEknd/m8iWlAqZtpZOQF6cTA1fizwhADmjvA9DsLSXsc3 TtxjoHVdBey9w5PfXeR1/ADtfP0F/uvwdHcCWbXKUhrJ8QYIFzj5o6YblzxuzCJn tKyfhmySKX/KG6pr/uXzgRr7VigSE3kOdZHM/7WdauoEpK49JuY4apCvziPUml2v tatH7M2P7GrX6dLUARFk0Ri21ORcniP4nCxQM8oHTRJEHauV0MoLwRbEOlFZh70Q M+YZUAHu57mf1z7XHzGQQiBoL0vnE9LEHSPxNnfdgLHvtNo9pI9N2eyrPCaWRVbF 9XQhkJ0HF5d9iii1hjbXGFf5c5y+Nb09rYqvTx0v99em8V6TIr0b82LfGrE/DPzk YQguiAwiRn7gJ2L6397o =32Ti -----END PGP SIGNATURE----- From nobody Mon Mar 17 01:01:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6261A03BA for ; Mon, 17 Mar 2014 01:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 uZGkWBqKO-dp for ; Mon, 17 Mar 2014 01:01:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 426E71A004C for ; Mon, 17 Mar 2014 01:01:04 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2H80mGv003472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Mar 2014 04:00:49 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2H80jxt009843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 17 Mar 2014 04:00:47 -0400 Message-ID: <1395043245.23812.4.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Watson Ladd Date: Mon, 17 Mar 2014 09:00:45 +0100 In-Reply-To: References: <5325DDA0.9030006@nthpermutation.com> <53260C51.10407@nthpermutation.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZS-4zcelfEpoZyp8htDgtdh3u5o Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 08:01:06 -0000 On Sun, 2014-03-16 at 21:23 -0700, Watson Ladd wrote: > Dear Mr. StJohns, > > Suppose you work at the Chinese Ministry of Truth, in the department > of web truthmaking, domain forgetting division. > Right now, if you want to ensure HTTP content is in conformance with > the truth you simply scan for the Host header and check against a > list. > For HTTPS life could get nasty. But luckily we decided to put SNI > information on the outside, so you can see if that connection needs to > go down the memory hole. I think this is a common misconception. SNI places the hostname in the clear, but that was already available. It is present in plain in both the DNS request and the certificate sent by the TLS server. SNI allowed the server to properly select the correct certificate when multi-hosting, but didn't really modify the existing privacy level. What I believe is the actual privacy issue there, are the cleartext certificates (client and server) in TLS. After that issue is addressed, only DNS will remain. regards, Nikos From nobody Mon Mar 17 07:42:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108E11A0400 for ; Mon, 17 Mar 2014 07:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6uyGnW0D7WK for ; Mon, 17 Mar 2014 07:42:04 -0700 (PDT) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id A3F691A02DF for ; Mon, 17 Mar 2014 07:42:04 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id b15so4217970eek.34 for ; Mon, 17 Mar 2014 07:41:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Dmjvdynzn/9JVZkZapZPJdT7mi50yzcZNimvPENfDOo=; b=nC3fDLlvfr2RGiMvbFZWJ5KCgbKQZ2SfeaUFO/v9A8NMRe8P4qSKfnx19Hs/Pv34b3 mFstt9Ww9a6KiAGeDLqAc8OGy/URuMOhOhM6mEVJO7LpJsS+0o8A5xnzE05SUNF+I3ZR Xd6a99u6Z7HEsGeJXkNP/3bKt6KMUqmAJrs4UgmZLHms1XkSXa08NWNo7rDI/6XyUN1U EqyEhkCUXlwdVXlO+PLiv6X0EW0k/LWCi6tH67/a65dn9OsvkuWwnC6tb9t9foHi26YL iMW7V6q+3Tlzu10RAwSJsMQEKcPxOinqlT49ViHkeLsqER80UtdlBEIXTU4wYjMUayQq j2FQ== X-Gm-Message-State: ALoCoQnqiTveDzn26qkvP7rSj/0IiHHlkVL39ofRf9koZ9LhwfqTX/q419d/KkvCTa0N8tKdOXAF X-Received: by 10.15.54.137 with SMTP id t9mr24090312eew.39.1395067316300; Mon, 17 Mar 2014 07:41:56 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id q44sm39952903eez.1.2014.03.17.07.41.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Mar 2014 07:41:55 -0700 (PDT) Message-ID: <532709B1.6030800@nthpermutation.com> Date: Mon, 17 Mar 2014 10:41:53 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Tom Ritter References: <5325DDA0.9030006@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uVuya3s1BOG_XVVIaxIoBsR0sgI Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 14:42:07 -0000 On 3/16/2014 9:43 PM, Tom Ritter wrote: > On 16 March 2014 10:21, Michael StJohns wrote: >> During the TLS meeting EKR talked about encrypting most of the protocol >> negotiation, and noted that the primary use case for that was the SNI. > What about protecting the certificate sent by the server? > What about protecting supported ciphersuites and extensions listed - > taking steps towards protecting what user agent is being used? > What about client certificates - protecting identity of the client? > What about extensions? SRP Data, Client/Server Auth data, Padding? Sorry - I should have put it like this (which AFAIK reflects the F2F discussion): SNI is the only one of these that needs to be sent upfront - the rest can be done (albeit expensively) at later stages of the negotiation. > If we had this before, the DHE exchange would be protected and we > wouldn't be exposing 1024 DH all over the place. I don't actually understand this point. You're saying because the DH negotiation is encrypted under a key negotiated by a previous DH negotiation, then 1024 bit DH would be safe? > > If we spend all our time focusing on trying to protect individual > components, we'll find arguments against any of them. I'd much rather > start from the perspective of protecting everything and address > problems on an individual basis. When building a cryptographic > protocol you don't choose the smallest security margin you can think > of for the application. All of this is motherhood I agree with except with "protecting everything" because TANSTAAFL - there ain't no such thing as a free lunch - everything costs and sometimes provides little benefit. But 1) what problem is this trying to solve? 2) How much cost is involved - on the client side and on the server side? 3) How much does this increase the attackers work factor? These are all question I look at before deciding to move forward with a solution. I'm unclear that we've agreed on the problem we're trying to solve (or problems), (And encrypt everything is not the problem, its the tool). Mike > > -tom From nobody Mon Mar 17 07:44:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60961A0401 for ; Mon, 17 Mar 2014 07:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3Tth7h7oHEs for ; Mon, 17 Mar 2014 07:43:56 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 964B91A0415 for ; Mon, 17 Mar 2014 07:43:55 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 4773C1A00AB; Mon, 17 Mar 2014 15:43:46 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aVNym59cY7tF; Mon, 17 Mar 2014 15:43:45 +0100 (CET) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id 438261A00A9; Mon, 17 Mar 2014 15:43:45 +0100 (CET) Received: from [10.53.40.204] (port=47875 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1WPYeS-0007wq-TD; Mon, 17 Mar 2014 15:36:28 +0100 Received: from [10.208.1.57] (10.208.1.57) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 17 Mar 2014 15:43:45 +0100 Message-ID: <53270A20.2000506@secunet.com> Date: Mon, 17 Mar 2014 15:43:44 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: , X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.57] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/082p1VtUKvPPMBVb7XHu88xJTC4 Cc: tls@ietf.org Subject: [TLS] draft-sheffer-tls-bcp-02 and signature algorithm extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Mar 2014 14:43:59 -0000 Yaron, Ralf, shouldn't draft-sheffer-tls-bcp-02 also give recommendations for clients on signaling minimum required hash functions via the signature algorithm extensions? -- Johannes From nobody Mon Mar 17 08:09:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EDA1A0401 for ; Mon, 17 Mar 2014 08:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPIOzkp6FJBj for ; Mon, 17 Mar 2014 08:09:15 -0700 (PDT) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id 138F01A014D for ; Mon, 17 Mar 2014 08:09:14 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id c41so4231128eek.36 for ; Mon, 17 Mar 2014 08:09:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4/joxz4lIuPO8j9g3cTX05pCY9IxUVKARqcgZSv59as=; b=D0MxKV1Qvz/0tK4BhvSNouXMgJ/dM0tlmjlfYIJlHx8Ks8vglrKR0ina9mhmA9IKQX xGWbnQeDI4AL4gE4lT6RGGaS07BbznCQPigYvpNWi9+0x2BFqlb5lawvP2EzVjQMz/yn 5lt7O3Jp2ejiSmf2/kBi/CFJZgCumF/KBNTbSElokOO/x/cGyBjn1Y9DpjbnhdnTntUa jMIFacZOtAjhNxTcat+NK9RelQOG+swd4Eoc/qblWOL6A4HXUX51Ns+PEEjhmVsL6b59 kO/m+stkaGmzi4DZRUVnxTfZrQbTgxE0V1X09Ew8EGaOcdKVRPOtszbB5UV5NS/6VGay y4kw== X-Gm-Message-State: ALoCoQkT4mHhXw8rfIfuUfOBzZ2nndRmMySvdIFJiaE7aVTQtoftBItOEUmvH+rWq4Ts5Z7vcL7w X-Received: by 10.14.225.132 with SMTP id z4mr3463785eep.92.1395068937323; Mon, 17 Mar 2014 08:08:57 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id e42sm27761092eev.32.2014.03.17.08.08.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Mar 2014 08:08:56 -0700 (PDT) Message-ID: <53271007.8050902@nthpermutation.com> Date: Mon, 17 Mar 2014 11:08:55 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Watson Ladd References: <5325DDA0.9030006@nthpermutation.com> <53260C51.10407@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/L-3Lf77NQhEYcJPIuDofdwDdQaw Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 15:09:21 -0000 On 3/17/2014 12:23 AM, Watson Ladd wrote: > Dear Mr. StJohns, > > Suppose you work at the Chinese Ministry of Truth, in the department > of web truthmaking, domain forgetting division. > > Right now, if you want to ensure HTTP content is in conformance with > the truth you simply scan for the Host header and check against a > list. > > For HTTPS life could get nasty. But luckily we decided to put SNI > information on the outside, so you can see if that connection needs to > go down the memory hole. Or the CMT just blocks all access to the device because its a known SNI encryption box. If you get to assign super powers to an entity to make your point, then so do I. > > Now you hear about this TLS 1.3 coming along, and how it obfuscates > SNI. So you present the following design to your boss: > 1: Each device on the filtering maintains a global IP->[Hosts] mapping. > 2: When an obfuscated SNI comes along, you check against all hosts in > the mapping > 3: If it is marked as untruthful block > 4: If unknown, transmit it to a dedicated cracking machine. > > Within a week the cracking machine is likely to figure out what the > hostname is, at which point it can be added to the list. If the agents > watching the spreading of untruth see a domain, we can just add it. > The computational cost will never exceed that of the hosting device. > > Your proposal doesn't stop censorship or even make it more expensive. > It doesn't hide visits to websites effectively if the attacker is > interested in checking against a big list. It doesn't accomplish any > of the goals we need it to. And unfortunately, I don't think EKRs proposal does it either. There are a few things you need to do symmetric encryption - a mutual key and an agreed upon cipher suite. EKR proposes retaining the keys and suite from a previous connection and using them to encrypt the negotiation for the next connection. To do this, both client and server cache the previous keys. If you have no previous connection, or you or the server have timed out the cached keys, EKR has you fall back to doing an unencrypted negotiation followed by an encrypted negotiation. Unfortunately, as I understand how this works, the SNI needs to be in the first negotiation so that the director can steer the packets to the appropriate server. Assuming super powers that let me twiddle with packets in flight - I modify the MAC over the negotiation records to cause it to fail verification at the server. Or I intercept the response from the server and replace it with an unsigned "sorry, no cached key" error message. Either way causing the client to fall back into unencrypted mode. This gets worse when the virtual server director isn't actually on the same server as the actual server, as the director will need copies of the keys in the same timely fashion as the servers. And that makes the director a big juicy target. (Seriously a single box with all the session keys for 1000s of sessions with 100s of servers? Let me at it) The threat could be partly mitigated by deriving a separate set of keys for "next session encryption negotiation", but that would change the current key expansion stages a bit. And still begs the question of how keys get from the virtual server to the director so this can be done. Another approach might be for the client (only) to retain the public key of the specific destination server, or a special use public key handed to the client by the server as part of another negotiation (and which related private key is shared with the director - said key being very long lived). Use that to encrypt the SNI (either RSA encryption, or something like ECIES for elliptic curve). And even use that as the encryption over the negotiation. Mike > > Sincerely, > Watson Ladd From nobody Mon Mar 17 08:26:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA2C1A040E for ; Mon, 17 Mar 2014 08:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=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 dTlGcTPsyqDw for ; Mon, 17 Mar 2014 08:26:29 -0700 (PDT) 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 CA0DE1A0409 for ; Mon, 17 Mar 2014 08:26:28 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id il7so5889292vcb.18 for ; Mon, 17 Mar 2014 08:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MmsLzFmDBArmJDv+AQO3FrvDMOcrkEPsswe+B7gS9Eo=; b=gaCMmcemCJfFY1RhjlRoHwzUq1M4v9TnmS19Nr4v7XhStiHgtGE7KfHiBhUan8kpfZ lG1z7rJvLduEP/JAL62bX79b/IaM82orD1ec4c4JLyJ0AzN5xIXVMYUT89iH7Jb393OQ K0+P+9Z9xDORhwPilrGp7HpNNzh2QrS92mvy7lvo/clFmq1dFjRt+8dnNXraa0chK8vn buDRJLnl9h+a7TBWP9KGcdlpfwjqCziKhp7xjWq5MT9Ocj7Hzgxi0zDs7lac/OAdjq/j J3+4rz9AunEZU9ZYW1ceOx2XwU4BG9kE07L1NhCmP2l9z1KwtYKClxTiO7pYTxoqX7Zn doXg== MIME-Version: 1.0 X-Received: by 10.52.183.106 with SMTP id el10mr6205vdc.73.1395069980708; Mon, 17 Mar 2014 08:26:20 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.220.91.132 with HTTP; Mon, 17 Mar 2014 08:26:20 -0700 (PDT) In-Reply-To: <53263807.9020005@nthpermutation.com> References: <5325DDA0.9030006@nthpermutation.com> <53260C51.10407@nthpermutation.com> <53263807.9020005@nthpermutation.com> Date: Mon, 17 Mar 2014 11:26:20 -0400 X-Google-Sender-Auth: 1ELrNdCv24ZBuG7LTcx37X3GN4E Message-ID: From: Erik Nygren To: Michael StJohns Content-Type: multipart/alternative; boundary=bcaec547cb97a3178f04f4cf0a2d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HdB9p7V5NZcbMKtVsl87WMlkPmI Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 15:26:31 -0000 --bcaec547cb97a3178f04f4cf0a2d Content-Type: text/plain; charset=ISO-8859-1 As someone mentioned in London, the SNI header is layer-7 routing information (similar to how the IP address is layer-3 routing information and the TCP port is layer-4 routing info). As much as we would all (hopefully?) love to protect it from a privacy perspective, it may turn out to be hard to do so in today's Internet without making hard trade-offs. The cases where encrypting SNI has value is where there is a 1:many association between IP and ServerName (including in cases where the server with the keys is on a different physical machine and perhaps different trust domain from the server terminating the TCP connection). But those are also the cases hard to implement here. Today (due to lack of adequate client adoption of SNI), many servers just use a 1:1 association here. > I think what we're getting to is that if we have a system where there is a middle box, then neither of these approaches > makes a lot of sense for the scale you're talking about? Right, especially in the case where the middle box is just a load-balancer or demuxer and doesn't have the keying information. Take the example of a virtual hosting cloud provider that has a TCP-terminating load balancer with public addresses that clients connect to (perhaps tens or hundreds of IPv4 addresses?) and then has a large pool of servers behind it operated by different entities with no shared trust (in private or IPv6 address space, perhaps with each backend server having many hostnames). In HTTP, the load balancer can just use the Host header to route traffic to the right place. With TLS without SNI, an IP address is needed per cert (which doesn't scale in IPv4 to allow pervasive use of TLS). With unencrypted SNI, the load balancer can demux connections to the proper server based on the SNI header. With encrypted SNI, this only works if there's an additional round-trip and the SNI header (and server cert and other things we want to protect) are covered by a key in the load balancer's trust domain (with that key never being used for anything sensitive). The end result of the encrypting at the client-hello level is thus opportunistic, with the similar effective results as if ipsec with anonymous was used to encrypt the connection (with TLS with SNI-in-the-clear then being over the ipsec connection). There are hundreds of millions of websites out there, all being handled by a highly heterogeneous mix of cloud providers, single server deployments, CDNs, embedded devices, and more. If we want to get pervasive TLS out there, we need to make sure that it can be deployed in all of these. Getting adequate TLS SNI adoption in clients is one of the gating factors for more pervasive use of TLS, and if we break the ability to use TLS SNI with adequate performance/cost in some of the key deployment scenarios then it could be a barrier to adoption. Erik On Sun, Mar 16, 2014 at 7:47 PM, Michael StJohns wrote: > On 3/16/2014 5:31 PM, Erik Nygren wrote: > >> Pros helping the passive anti-privacy attacker: they also have server IP >> address to constrain the problem space by, plus TLS 1.2 SNIs so if there >> are a 100k hostnames behind the middlebox then that's their search space. >> >> Pros helping the DDoS attacker: they can just send random hash+opaque >> values. The middle box needs to then calculate the hash for all of the >> hostnames (eg, perhaps 100k in the same scenario above). >> > > I don't disagree with any of your points (but there's always a tradeoff > between DOS protections and negotiation protections), but I wanted to focus > on the 100K. > > The question is - if the SNI is encrypted from the client to the end > system, how do the end systems communicate with the middle box to pass on > their key info and keep it up to date - not on a per-box 100K basis, but on > a 100K times the number of connections per box? > > I think what we're getting to is that if we have a system where there is a > middle box, then neither of these approaches makes a lot of sense for the > scale you're talking about? > > Mike > > --bcaec547cb97a3178f04f4cf0a2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As someone mentioned in London, the SNI hea= der is layer-7 routing information (similar to how the IP address is layer-3 routing=20 information and the TCP port is layer-4 routing info).=A0 As much as we=20 would all (hopefully?) love to protect it from a privacy perspective, it may turn out to be hard to do so in today's Internet without making=20 hard trade-offs.=A0 The cases where encrypting SNI has value is where=20 there is a 1:many association between IP and ServerName (including in=20 cases where the server with the keys is on a different physical machine=20 and perhaps different trust domain from the server terminating the TCP=20 connection).=A0 But those are also the cases hard to implement here.=A0=20 Today (due to lack of adequate client adoption of SNI), many servers=20 just use a 1:1 association here.

> I think what we're getting= to is that if we have a system where there is a middle box, then neither of these approaches
> makes a lot of sen= se for the scale you're talking about?

Right, especially in the = case where the middle box is just a load-balancer or demuxer and doesn'= t have the keying information.=A0 Take the example of a virtual hosting clo= ud provider that has a TCP-terminating load balancer with public addresses = that clients connect to (perhaps tens or hundreds of IPv4 addresses?) and t= hen has a large pool of servers behind it operated by different entities wi= th no shared trust (in private or IPv6 address space, perhaps with each bac= kend server having many hostnames).=A0 In HTTP, the load balancer can just = use the Host header to route traffic to the right place.=A0 With TLS withou= t SNI, an IP address is needed per cert (which doesn't scale in IPv4 to= allow pervasive use of TLS).=A0 With unencrypted SNI, the load balancer ca= n demux connections to the proper server based on the SNI header. With encr= ypted SNI, this only works if there's an additional round-trip and the = SNI header (and server cert and other things we want to protect) are covere= d by a key in the load balancer's trust domain (with that key never bei= ng used for anything sensitive).=A0 The end result of the encrypting at the= client-hello level is thus opportunistic, with the similar effective resul= ts as if ipsec with anonymous was used to encrypt the connection (with TLS = with SNI-in-the-clear then being over the ipsec connection).

There are hundreds of millions of websites out there, all being h= andled by a highly heterogeneous mix of cloud providers, single server depl= oyments, CDNs, embedded devices, and more.=A0 If we want to get pervasive T= LS out there, we need to make sure that it can be deployed in all of these.= =A0 Getting adequate TLS SNI adoption in clients is one of the gating facto= rs for more pervasive use of TLS, and if we break the ability to use TLS SN= I with adequate performance/cost in some of the key deployment scenarios th= en it could be a barrier to adoption.

=A0=A0=A0 Erik



On Sun, Mar 16, 2014 at 7:47= PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 3/16/2014 5:31 PM, Erik N= ygren wrote:
Pros helping the passive anti-privacy attacker: =A0they also have server IP= address to constrain the problem space by, plus TLS 1.2 SNIs so if there a= re a 100k hostnames behind the middlebox then that's their search space= .

Pros helping the DDoS attacker: they can just send random hash+opaque value= s. =A0The middle box needs to then calculate the hash for all of the hostna= mes (eg, perhaps 100k in the same scenario above).

I don't disagree with any of your points (but there's always a trad= eoff between DOS protections and negotiation protections), but I wanted to = focus on the 100K.

The question is - if the SNI is encrypted from the client to the end system= , how do the end systems communicate with the middle box to pass on their k= ey info and keep it up to date - not on a per-box 100K basis, but on a 100K= times the number of connections per box?

I think what we're getting to is that if we have a system where there i= s a middle box, then neither of these approaches makes a lot of sense for t= he scale you're talking about?

Mike


--bcaec547cb97a3178f04f4cf0a2d-- From nobody Mon Mar 17 08:34:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D621A0423 for ; Mon, 17 Mar 2014 08:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMaxMb4aqav7 for ; Mon, 17 Mar 2014 08:33:59 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED531A02FD for ; Mon, 17 Mar 2014 08:33:58 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p61so4760893wes.13 for ; Mon, 17 Mar 2014 08:33:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=F7QdJdQhgvS9A8kCZTPOsQE9hwUor12GSgZ6YZ5AulU=; b=gDSMNB9vQ3O9GrKBTA5AUSTU2cIMXsegjAqEgnxpNwmRgr+61k/LyD9fPek9padr3Y uV37ugpOT2R5ci858xYeRAe23+pvBFhHiG9uicwCDH/xS6Qk/wzQggP30ix3zl8p3pcA 4hWnR4q5++quyo554lAp6qBeNYpqE3kr6B0cQSuHFa5CN1Np8IwUmui4FQk/Ic1rcgcp sOvkmwmQN0HJiziP69+i22l02n09r2oOzI4suz1w/vbBeQ6Ly/6YuEpQbh1rISJ413Ve EjqK0GQvIzlT+H+Kgl5L8Oc1LcNT8hoMvLuPg3se/Nfuh3AZcESy5nmV4aBd2D2E8OLp iyWg== X-Gm-Message-State: ALoCoQlnF52EWAY1ZgNyoudoA3HntTl9ESt7ODMHSAFPDetR+D1fM2L2ETh8zpWJZV5cMOqARDdd X-Received: by 10.180.164.174 with SMTP id yr14mr10091909wib.18.1395070430634; Mon, 17 Mar 2014 08:33:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Mon, 17 Mar 2014 08:33:10 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <53271007.8050902@nthpermutation.com> References: <5325DDA0.9030006@nthpermutation.com> <53260C51.10407@nthpermutation.com> <53271007.8050902@nthpermutation.com> From: Eric Rescorla Date: Mon, 17 Mar 2014 08:33:10 -0700 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=00248c0d791474816104f4cf2548 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hAMzztETMS0JmdyHIRmZi7K6Hm0 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 15:34:02 -0000 --00248c0d791474816104f4cf2548 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 17, 2014 at 8:08 AM, Michael StJohns wrote: > On 3/17/2014 12:23 AM, Watson Ladd wrote: > >> Dear Mr. StJohns, >> >> Suppose you work at the Chinese Ministry of Truth, in the department >> of web truthmaking, domain forgetting division. >> >> Right now, if you want to ensure HTTP content is in conformance with >> the truth you simply scan for the Host header and check against a >> list. >> >> For HTTPS life could get nasty. But luckily we decided to put SNI >> information on the outside, so you can see if that connection needs to >> go down the memory hole. >> > > Or the CMT just blocks all access to the device because its a known SNI > encryption box. If you get to assign super powers to an entity to make > your point, then so do I. > > > >> Now you hear about this TLS 1.3 coming along, and how it obfuscates >> SNI. So you present the following design to your boss: >> 1: Each device on the filtering maintains a global IP->[Hosts] mapping. >> 2: When an obfuscated SNI comes along, you check against all hosts in >> the mapping >> 3: If it is marked as untruthful block >> 4: If unknown, transmit it to a dedicated cracking machine. >> >> Within a week the cracking machine is likely to figure out what the >> hostname is, at which point it can be added to the list. If the agents >> watching the spreading of untruth see a domain, we can just add it. >> The computational cost will never exceed that of the hosting device. >> >> Your proposal doesn't stop censorship or even make it more expensive. >> It doesn't hide visits to websites effectively if the attacker is >> interested in checking against a big list. It doesn't accomplish any >> of the goals we need it to. >> > > And unfortunately, I don't think EKRs proposal does it either. > > There are a few things you need to do symmetric encryption - a mutual key > and an agreed upon cipher suite. EKR proposes retaining the keys and suite > from a previous connection and using them to encrypt the negotiation for > the next connection. To do this, both client and server cache the previous > keys. If you have no previous connection, or you or the server have timed > out the cached keys, EKR has you fall back to doing an unencrypted > negotiation followed by an encrypted negotiation. Unfortunately, as I > understand how this works, the SNI needs to be in the first negotiation so > that the director can steer the packets to the appropriate server. > Just for clarity, this is not quite what I was proposing. Rather, I was proposing that if the cached keys expired, you did an anonymous DH exchange, so you get protection for the target server against passive attack but not active attack. I agree that you can mount an active attack as suggested below, though it cannot be done totally transparently. This gets worse when the virtual server director isn't actually on the same > server as the actual server, as the director will need copies of the keys > in the same timely fashion as the servers. And that makes the director a > big juicy target. (Seriously a single box with all the session keys for > 1000s of sessions with 100s of servers? Let me at it) Note that this situation is a fairly standard configuration for SSL acceleration devices in any case. What's different here is primarily that the load balancer is not generally required to be trusted. > The threat could be partly mitigated by deriving a separate set of keys > for "next session encryption negotiation", but that would change the > current key expansion stages a bit. And still begs the question of how > keys get from the virtual server to the director so this can be done. > > Another approach might be for the client (only) to retain the public key > of the specific destination server, or a special use public key handed to > the client by the server as part of another negotiation (and which related > private key is shared with the director - said key being very long lived). > Use that to encrypt the SNI (either RSA encryption, or something like > ECIES for elliptic curve). And even use that as the encryption over the > negotiation. Without digging too much into the details just yet, it seems to me that the key element if you want to have protection against active attack is that the client must be able to directly verify that a given key is owned by the server in a way that cannot be substituted by the attacker. The challenge, of course, is that the information that the server uses to authenticate that key inherently reveals the server's identity. I see two basic options [0]: - Have the client acquire the server's key over some untrusted channel and accept that it can be monitored the first time. - Have the server provide a large set of keys (like all the ones that it supports) to the client and then the client can choose one. Note that in either case, this represents a commitment by the server to use that key through it's expiry window. i.e., it's hard state rather than soft state, which people have been so far reluctant to do with HPKP. Both of these have obvious drawbacks, so it's a compromise. -Ekr [0] I'm assuming we restrict ourselves entirely to the TLS channel. If we are willing to have data in, for instance, the DNS, there are other options for disseminating the initial key data. --00248c0d791474816104f4cf2548 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 17, 2014 at 8:08 AM, Michael StJohns = <msj@nthperm= utation.com> wrote:
On 3/17/2014 12:23 AM, Watso= n Ladd wrote:
Dear Mr. StJohns,

Suppose you work at the Chinese Ministry of Truth, in the department
of web truthmaking, domain forgetting division.

Right now, if you want to ensure HTTP content is in conformance with
the truth you simply scan for the Host header and check against a
list.

For HTTPS life could get nasty. But luckily we decided to put SNI
information on the outside, so you can see if that connection needs to
go down the memory hole.

Or the CMT just blocks all access to the device because its a known SNI enc= ryption box. =A0 =A0If you get to assign super powers to an entity to make = your point, then so do I.



Now you hear about this TLS 1.3 coming along, and how it obfuscates
SNI. So you present the following design to your boss:
1: Each device on the filtering maintains a global IP->[Hosts] mapping.<= br> 2: When an obfuscated SNI comes along, you check against all hosts in
the mapping
3: If it is marked as untruthful block
4: If unknown, transmit it to a dedicated cracking machine.

Within a week the cracking machine is likely to figure out what the
hostname is, at which point it can be added to the list. If the agents
watching the spreading of untruth see a domain, we can just add it.
The computational cost will never exceed that of the hosting device.

Your proposal doesn't stop censorship or even make it more expensive. It doesn't hide visits to websites effectively if the attacker is
interested in checking against a big list. It doesn't accomplish any of the goals we need it to.

And unfortunately, I don't think EKRs proposal does it either.

There are a few things you need to do symmetric encryption - a mutual key a= nd an agreed upon cipher suite. =A0EKR proposes retaining the keys and suit= e from a previous connection and using them to encrypt the negotiation for = the next connection. =A0To do this, both client and server cache the previo= us keys. =A0 If you have no previous connection, or you or the server have = timed out the cached keys, EKR has you fall back to doing an unencrypted ne= gotiation followed by an encrypted negotiation. =A0Unfortunately, as I unde= rstand how this works, the SNI needs to be in the first negotiation so that= the director can steer the packets to the appropriate server.

Just for clarity, this is not quite what I= was proposing. Rather, I was
proposing that if the cached keys e= xpired, you did an anonymous
DH exchange, so you get protection f= or the target server against
passive attack but not active attack. I agree that you can mount
=
an active attack as suggested below, though it cannot be done
totally transparently.


This gets worse when the virtual server director isn't actually on the = same server as the actual server, as the director will need copies of the k= eys in the same timely fashion as the servers. =A0And that makes the direct= or a big juicy target. =A0(Seriously a single box with all the session keys= for 1000s of sessions with 100s of servers? Let me at it)

Note that this situation is a fairly standard configura= tion for SSL acceleration
devices in any case. What's differe= nt here is primarily that the load balancer
is not generally requ= ired to be trusted.


=A0
= =A0The threat could be partly mitigated by deriving a separate set of keys= for "next session encryption negotiation", but that would change= the current key expansion stages a bit. =A0And still begs the question of = how keys get from the virtual server to the director so this can be done.
Another approach might be for the client (only) to retain the public key of= the specific destination server, or a special use public key handed to the= client by the server as part of another negotiation (and which related pri= vate key is shared with the director - said key being very long lived). =A0= Use that to encrypt the SNI (either RSA encryption, or something like ECIES= for elliptic curve). =A0 =A0 And even use that as the encryption over the = negotiation.

Without digging too much into the details just yet, it = seems to me
that the key element if you want to have protection a= gainst active
attack is that the client must be able to directly = verify that a given
key is owned by the server in a way that cannot be substituted by
the attacker. The challenge, of course, is that the information
=
that the server uses to authenticate that key inherently reveals
the server's identity. I see two basic options [0]:

=
- Have the client acquire the server's key over some untrust= ed channel
and accept that it can be monitored the first time.

- Have the server provide a large set of keys (like all= the ones that
it supports) to the client and then the client can= choose one.

Note that in either case, this repres= ents a commitment by the server to
use that key through it's expiry window. i.e., it's hard state= rather
than soft state, which people have been so far reluctant = to do with
HPKP. Both of these have obvious drawbacks, so it'= s a
compromise.=A0

-Ekr

<= div>[0] I'm assuming we restrict ourselves entirely to the TLS channel.=
If we are willing to have data in, for instance, the DNS, there = are other
options for disseminating the initial key data.

--00248c0d791474816104f4cf2548-- From nobody Mon Mar 17 09:54:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92AA1A006F for ; Mon, 17 Mar 2014 09:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V6zub65T9-N for ; Mon, 17 Mar 2014 09:54:45 -0700 (PDT) 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 F18481A043E for ; Mon, 17 Mar 2014 09:54:43 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so4787411wgg.33 for ; Mon, 17 Mar 2014 09:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9zHikKeGs6NCQvsqW6QsMwVkz83nuH20WXoayu1P+I0=; b=WcZtuO3s3xzTobRpFRYGgxpL1QUA1C5Auh7PIj7S/R9J+uIsY4i/zix+vybK4r/SNl 6rwWQ5LD9HY/9jhpeo4IThTEJwClR/TB3odX8h5KJawO7X56sXfoshHO5Sgmun7pFu4Y o0C3Xf+b28YvHhYhAGNGgje2rUn6Vs6corFZ10Y2Sdf/PSVbhtK4FRcs0TWTO2WXSrhQ qqX5CQ6soXbVF+NZ/4Esb06yxNchOABvASM6EXhSz2NMc2dPcUHU7CKZ+MkdG8ZL4ma4 zF4uZuyc/s0KoIQ5jQkYo1zrruKQtRXn6au1krUPhsNoM2nlrbPYGWY/vEFK3YX70wr6 8WpA== X-Received: by 10.180.25.46 with SMTP id z14mr10283770wif.49.1395075275551; Mon, 17 Mar 2014 09:54:35 -0700 (PDT) Received: from [10.2.0.25] (85-250-94-150.bb.netvision.net.il. [85.250.94.150]) by mx.google.com with ESMTPSA id r1sm25856980wia.5.2014.03.17.09.54.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Mar 2014 09:54:34 -0700 (PDT) Message-ID: <532728C9.9010600@gmail.com> Date: Mon, 17 Mar 2014 18:54:33 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Johannes Merkle , holz@net.in.tum.de References: <53270A20.2000506@secunet.com> In-Reply-To: <53270A20.2000506@secunet.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mtJwZw9cK5WBjO9WsuFsjMqmHSQ Cc: tls@ietf.org Subject: Re: [TLS] draft-sheffer-tls-bcp-02 and signature algorithm extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Mar 2014 16:54:47 -0000 Hi Johannes, Can you please post the question to the UTA WG list, which is where this draft has moved to. Thanks, Yaron On 03/17/2014 04:43 PM, Johannes Merkle wrote: > Yaron, Ralf, > > shouldn't draft-sheffer-tls-bcp-02 also give recommendations for clients on signaling minimum required hash functions > via the signature algorithm extensions? > From nobody Mon Mar 17 20:23:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9618E1A0349 for ; Mon, 17 Mar 2014 20:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pVWm3jbPyW37 for ; Mon, 17 Mar 2014 20:23:34 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 070031A0233 for ; Mon, 17 Mar 2014 20:23:33 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id x10so6417608pdj.6 for ; Mon, 17 Mar 2014 20:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fQ8tWT9RI87PcryOqNBD2WMEve0Ey9I3FLHtMsn29Ss=; b=wwUWRYyEcN7LG+8eD7rFf+eQT2rMskk23/7whrocPBx+5gDX8Wxy/fGtvkECiP2ZJb GbwwfJls3x2efM2RRe4Oz7qT5ZYKbkLixWYNTdS8MbSZy7tfSc/ESXsVcmMa5KFNHqcz 8KiygMjgk9/JyVjG4HYW2Ik9h4koJpO+tRFdk= 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=fQ8tWT9RI87PcryOqNBD2WMEve0Ey9I3FLHtMsn29Ss=; b=jDgeG9Z7QZVDYtrcFCy+Lnqqm4IlCXDelk9KHx31discSf0C3XuX0MHI9Pw6P5Aau+ Qt9EQrelRMxTcPXtUZEJ9m+fWYrDmuDK7emV7vdF16QKvlFWRZ64CDHwY0FMsBxg8YFp hI/Zswtqins+FDkILwwp/k356WEBY3q52zvnOTiwdTbpCGzPBEbIrWXcMcaWLHDFrFI+ 5kTzndoAv+slQ1p3/sjCLlNgOw0V3NGZk2AZ47PDrJYosg7ZPwauR2Y/hvHjtYIXshDE D+MrJ3kMPDWNCuEc3RzsCtd2OPA4fLmFqWDUNJBunydOLERq2U8Pi8BdcivOvnf3T8PZ oX/w== X-Gm-Message-State: ALoCoQnExk0/wXypkc4POdPuLfO+j/esN1zoyPkwpgyrUkxq1o4usgjhmxBk3CkZs1PrrnIhLp/L X-Received: by 10.66.164.135 with SMTP id yq7mr12636233pab.126.1395113005238; Mon, 17 Mar 2014 20:23:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.198.68 with HTTP; Mon, 17 Mar 2014 20:23:04 -0700 (PDT) In-Reply-To: <532709B1.6030800@nthpermutation.com> References: <5325DDA0.9030006@nthpermutation.com> <532709B1.6030800@nthpermutation.com> From: Tom Ritter Date: Mon, 17 Mar 2014 20:23:04 -0700 Message-ID: To: Michael StJohns Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oZsgEwxm_J77iaiKI7Qvu9YQKi4 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 03:23:35 -0000 On 17 March 2014 07:41, Michael StJohns wrote: > On 3/16/2014 9:43 PM, Tom Ritter wrote: >> What about protecting the certificate sent by the server? >> What about protecting supported ciphersuites and extensions listed - >> taking steps towards protecting what user agent is being used? >> What about client certificates - protecting identity of the client? >> What about extensions? SRP Data, Client/Server Auth data, Padding? > > Sorry - I should have put it like this (which AFAIK reflects the F2F > discussion): > > SNI is the only one of these that needs to be sent upfront - the rest can be > done (albeit expensively) at later stages of the negotiation. That's fair, thanks. >> If we had this before, the DHE exchange would be protected and we >> wouldn't be exposing 1024 DH all over the place. > > I don't actually understand this point. You're saying because the DH > negotiation is encrypted under a key negotiated by a previous DH > negotiation, then 1024 bit DH would be safe? Nope, I'm saying if I'm waving a fairy wand and randomly rearchitecting protocols in the past, TLS _might_ have had the DHE negotiation occur inside a channel protected by the non-PFS RSA key. In my alternate world, we're able to upgrade the RSA key (1024, 2048, 4096) but due to annoying client restrictions, not the 1024 DH. And in the alternate world, the 1024 DH handshake is protected by the 2048 RSA - you can't attack the 1024 without breaking the 2048. (Like you can now.) It's just an example where data that was sent in the clear, instead of in a secure channel, enabled attacks in an unexpected way a decade or more later. >> If we spend all our time focusing on trying to protect individual >> components, we'll find arguments against any of them. I'd much rather >> start from the perspective of protecting everything and address >> problems on an individual basis. When building a cryptographic >> protocol you don't choose the smallest security margin you can think >> of for the application. > > > All of this is motherhood I agree with except with "protecting everything" > because TANSTAAFL - there ain't no such thing as a free lunch - everything > costs and sometimes provides little benefit. But 1) what problem is this > trying to solve? 2) How much cost is involved - on the client side and on > the server side? 3) How much does this increase the attackers work factor? > These are all question I look at before deciding to move forward with a > solution. > > I'm unclear that we've agreed on the problem we're trying to solve (or > problems), (And encrypt everything is not the problem, its the tool). That's fair. I imagine not everyone agrees with me when I see the problem as "The client communicates version information, options, and preferences outside a channel protected against a passive adversary. The client is unable to communicate information it deems very sensitive in a channel protected against an active adversary*." * I suppose the caveat there would be "in a way performant enough for anyone to use it" ;) The arguements I really disagree with are the ones of the form: - There's no reason to try and hide the options one supports, because the User-Agent will be sent at an earlier or later time in plaintext. - DNS lookups mean the data is exposed anyway, so who cares about it. These arguements assume a specific operating environment and model. While it's true it's common today, there is no guarentee that it will be true tomorrow, or that someone won't try and tackle those problems elsewhere. It's also violating the principal of layering - I shouldn't care what's happening at a different layer, I should make my thing independent and secure. I'm wondering if there is an approach here to hide the SNI against a passive adversary, but not an active adversary - with the ability to 'bolt-on' strong authentication of 'ephemeral' keys if the stronger protection is needed... -tom From nobody Mon Mar 17 20:34:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700D51A036C for ; Mon, 17 Mar 2014 20:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y1rLHzoRtpx for ; Mon, 17 Mar 2014 20:34:00 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBB11A035B for ; Mon, 17 Mar 2014 20:34:00 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id e16so6993268qcx.6 for ; Mon, 17 Mar 2014 20:33:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=2GXKTxhYvwyh17Oi9/Rf47rUOaqNpGchGx6YMys0Ges=; b=XYyxd+QMAsuhjq5+wLpCtLnS3f7rnoSEM8GRnqWSBEVdsNS6CfAiLTgxd+9MZTMWyI mC/Z4+ym1DCLjJfpTWE/r7kVFRcBBS4WHWIpZ8i9yUWSC8sMHDm/8660NYheAUNYmH5P hV+wwuH2XwYZ06d4TY93DUJ4OPvfFkw/9sPo4e4CV/uDfPJQy7KLrZDfEswf1BJJclpC dKO4F6v3mJGLOt+65f2W751x5zAx5nDBJ4VBJuN9wqleyMTk1fJvQzSQ3lLkcDN9Oge1 4vx35K2WDb3f+M2Hso+6LFHJlq6gG21bqkKjpBxBfpJz8kWHNsQWRsO86RKENYZnBvaR Qqlw== X-Gm-Message-State: ALoCoQmOPQ4xZ8xJpSz5b3zOLvFYcyxUCFq9K/TSCKYkR8MHwCfQdG1wd5P5MPw4rbqJx//x9Tom X-Received: by 10.224.161.140 with SMTP id r12mr32714253qax.24.1395113632122; Mon, 17 Mar 2014 20:33:52 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id 73sm24200762qgg.22.2014.03.17.20.33.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Mar 2014 20:33:51 -0700 (PDT) Message-ID: <5327BEA0.3050000@nthpermutation.com> Date: Mon, 17 Mar 2014 23:33:52 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Eric Rescorla References: <5325DDA0.9030006@nthpermutation.com> <53260C51.10407@nthpermutation.com> <53271007.8050902@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090109050607060400070805" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/17B32Zd_hjQ8rfD06sA2QRAq6kE Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 03:34:03 -0000 This is a multi-part message in MIME format. --------------090109050607060400070805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/17/2014 11:33 AM, Eric Rescorla wrote: > > > > On Mon, Mar 17, 2014 at 8:08 AM, Michael StJohns > > wrote: > > And unfortunately, I don't think EKRs proposal does it either. > > There are a few things you need to do symmetric encryption - a > mutual key and an agreed upon cipher suite. EKR proposes > retaining the keys and suite from a previous connection and using > them to encrypt the negotiation for the next connection. To do > this, both client and server cache the previous keys. If you > have no previous connection, or you or the server have timed out > the cached keys, EKR has you fall back to doing an unencrypted > negotiation followed by an encrypted negotiation. Unfortunately, > as I understand how this works, the SNI needs to be in the first > negotiation so that the director can steer the packets to the > appropriate server. > > > Just for clarity, this is not quite what I was proposing. Rather, I was > proposing that if the cached keys expired, you did an anonymous > DH exchange, so you get protection for the target server against > passive attack but not active attack. I agree that you can mount > an active attack as suggested below, though it cannot be done > totally transparently. Right - what I said - you do an unencrypted negotiation by offering an ANON suite or suites (probably the latter to prevent DH from becoming indispensible) in a clear text ClientHello. You then re-use the key from that negotiation to encrypt the re-negotiation handshake exchanges. > > > This gets worse when the virtual server director isn't actually on > the same server as the actual server, as the director will need > copies of the keys in the same timely fashion as the servers. And > that makes the director a big juicy target. (Seriously a single > box with all the session keys for 1000s of sessions with 100s of > servers? Let me at it) > > > Note that this situation is a fairly standard configuration for SSL > acceleration > devices in any case. What's different here is primarily that the load > balancer > is not generally required to be trusted. Yup. > > > The threat could be partly mitigated by deriving a separate set > of keys for "next session encryption negotiation", but that would > change the current key expansion stages a bit. And still begs the > question of how keys get from the virtual server to the director > so this can be done. > > Another approach might be for the client (only) to retain the > public key of the specific destination server, or a special use > public key handed to the client by the server as part of another > negotiation (and which related private key is shared with the > director - said key being very long lived). Use that to encrypt > the SNI (either RSA encryption, or something like ECIES for > elliptic curve). And even use that as the encryption over the > negotiation. > > > Without digging too much into the details just yet, it seems to me > that the key element if you want to have protection against active > attack is that the client must be able to directly verify that a given > key is owned by the server in a way that cannot be substituted by > the attacker. The challenge, of course, is that the information > that the server uses to authenticate that key inherently reveals > the server's identity. I see two basic options [0]: three? > > - Have the client acquire the server's key over some untrusted channel > and accept that it can be monitored the first time. > > - Have the server provide a large set of keys (like all the ones that > it supports) to the client and then the client can choose one. Do this as a public key operation instead of a symmetric key op, and have the server provide a public key specific to the "encrypt the handshake" protection during one of the prior connections. That gets cached by the client. I mention this for completeness. It has the benefit of not requiring the server to cache anything, but the potential downside of a DOS attack based on the cost to derive a key. But that's no worse than an ANON negotiation I think. If you cache the client public key and/or the derived shared secret you mostly eliminate that issue (but loses you some of the benefit of the approach). > > Note that in either case, this represents a commitment by the server to > use that key through it's expiry window. i.e., it's hard state rather > than soft state, which people have been so far reluctant to do with > HPKP. Both of these have obvious drawbacks, so it's a > compromise. > > -Ekr > > [0] I'm assuming we restrict ourselves entirely to the TLS channel. > If we are willing to have data in, for instance, the DNS, there are other > options for disseminating the initial key data. > --------------090109050607060400070805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 3/17/2014 11:33 AM, Eric Rescorla wrote:



On Mon, Mar 17, 2014 at 8:08 AM, Michael StJohns <msj@nthpermutation.com> wrote:
And unfortunately, I don't think EKRs proposal does it either.

There are a few things you need to do symmetric encryption - a mutual key and an agreed upon cipher suite.  EKR proposes retaining the keys and suite from a previous connection and using them to encrypt the negotiation for the next connection.  To do this, both client and server cache the previous keys.   If you have no previous connection, or you or the server have timed out the cached keys, EKR has you fall back to doing an unencrypted negotiation followed by an encrypted negotiation.  Unfortunately, as I understand how this works, the SNI needs to be in the first negotiation so that the director can steer the packets to the appropriate server.

Just for clarity, this is not quite what I was proposing. Rather, I was
proposing that if the cached keys expired, you did an anonymous
DH exchange, so you get protection for the target server against
passive attack but not active attack. I agree that you can mount
an active attack as suggested below, though it cannot be done
totally transparently.

Right - what I said - you do an unencrypted negotiation by offering an ANON suite or suites (probably the latter to prevent DH from becoming indispensible) in a clear text ClientHello.  You then re-use the key from that negotiation to encrypt the re-negotiation handshake exchanges.  



This gets worse when the virtual server director isn't actually on the same server as the actual server, as the director will need copies of the keys in the same timely fashion as the servers.  And that makes the director a big juicy target.  (Seriously a single box with all the session keys for 1000s of sessions with 100s of servers? Let me at it)

Note that this situation is a fairly standard configuration for SSL acceleration
devices in any case. What's different here is primarily that the load balancer
is not generally required to be trusted.

Yup. 



 
 The threat could be partly mitigated by deriving a separate set of keys for "next session encryption negotiation", but that would change the current key expansion stages a bit.  And still begs the question of how keys get from the virtual server to the director so this can be done.

Another approach might be for the client (only) to retain the public key of the specific destination server, or a special use public key handed to the client by the server as part of another negotiation (and which related private key is shared with the director - said key being very long lived).  Use that to encrypt the SNI (either RSA encryption, or something like ECIES for elliptic curve).     And even use that as the encryption over the negotiation.

Without digging too much into the details just yet, it seems to me
that the key element if you want to have protection against active
attack is that the client must be able to directly verify that a given
key is owned by the server in a way that cannot be substituted by
the attacker. The challenge, of course, is that the information
that the server uses to authenticate that key inherently reveals
the server's identity. I see two basic options [0]:
three?


- Have the client acquire the server's key over some untrusted channel
and accept that it can be monitored the first time.

- Have the server provide a large set of keys (like all the ones that
it supports) to the client and then the client can choose one.
Do this as a public key operation instead of a symmetric key op, and have the server provide a public key specific to the "encrypt the handshake" protection during one of the prior connections.  That gets cached by the client.

I mention this for completeness.  It has the benefit of not requiring the server to cache anything, but the potential downside of a DOS attack based on the cost to derive a key.  But that's no worse than an ANON negotiation I think.  If you cache the client public key and/or the derived shared secret you mostly eliminate that issue (but loses you some of the benefit of the approach).


Note that in either case, this represents a commitment by the server to
use that key through it's expiry window. i.e., it's hard state rather
than soft state, which people have been so far reluctant to do with
HPKP. Both of these have obvious drawbacks, so it's a
compromise. 

-Ekr

[0] I'm assuming we restrict ourselves entirely to the TLS channel.
If we are willing to have data in, for instance, the DNS, there are other
options for disseminating the initial key data.


--------------090109050607060400070805-- From nobody Tue Mar 18 09:05:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231D91A0410 for ; Tue, 18 Mar 2014 09:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 PhT8U4bTPsmM for ; Tue, 18 Mar 2014 09:05:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 69D321A040A for ; Tue, 18 Mar 2014 09:05:27 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:53086) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WPwW2-00077z-7s; Tue, 18 Mar 2014 12:05:22 -0400 Message-ID: <53286EBA.5090308@bbn.com> Date: Tue, 18 Mar 2014 12:05:14 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Sandeep Kumar References: <5318A8A6.50201@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/keRJXHIHDM_eCUKrP533CczfF4Q Cc: "tls@ietf.org" , Steve Kent Subject: Re: [TLS] where IVs come from (and other mysteries ...) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Mar 2014 16:05:29 -0000 Sandeep, Sorry to be so late in replying. > .... > > RFC5288 states that > struct { > opaque salt[4]; > opaque nonce_explicit[8]; > } GCMNonce; > > ...the salt is generated as part of the handshake > process: it is either the client_write_IV (when the client is > sending) or the server_write_IV (when the server is sending). > > Does it mean that the module generates the nonce_explicit or the whole > GCMNonce. If it's the latter then the sequence number checking on > the TLS packet will not help. The part of the structure labeled "salt" above is called the "fixed field" in NIST 800-38. The FIPS 140-2 implementation guidance doc says that if one generates the explicit nonce deterministically, e.g., using a counter or LFSR, then the fixed field represents the "name" of the module and the name needs to be long enough to allow for at least 2**32 distinct values. The name need not be generated internal to the module; according to Additional Comment #2, page 136, this field may be assigned by a user. So, in the context of interest, TLS could supply the salt to an evaluated module, but the module would generate the explicit nonce internally. There is separate test guidance if the whole IV were to be generated randomly, but we're not discussing that approach here, based on the RFC 5288 description you cited above. Steve From nobody Tue Mar 18 11:17:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19221A0724 for ; Tue, 18 Mar 2014 11:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 drlyej9Q0sMo for ; Tue, 18 Mar 2014 11:16:26 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id D17831A0775 for ; Tue, 18 Mar 2014 11:11:25 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id p10so7459112pdj.17 for ; Tue, 18 Mar 2014 11:11:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=+FzF8+DS80+Htmbu0smI035wlp3/xglXRzA0c+5GG1o=; b=CkTX7IyPLhWhLwbEhFvWo66gZX8gnyXkslxjeO/0Zl/5BLuBuRkqurbE1H78i7t9wf qgvQFRYbbBOI4gbUFjuMsteykYXMQkDmASKULqrgLu/9c2T3DpDi7xFd/Hm/YD90OgbN +i+R9wrFRzuzZ8smBwu1fafblV1rhjyOsbfwL43MZzThWcqdkGCSUkpseWpkNXvvXZfd rn7a1oVNP/s+com+WihwjGN365et+F07mvFaisF2GFytHvArGd+119R8zKMPtdD+IA72 kOzrGNbPZiMuIFEhG6dMSeWQnp2144+Ey+Bq/iXDQnO+eKe1CIrz5w1OUEgfFFkUjx25 As8A== X-Gm-Message-State: ALoCoQlp5GpZEgya8RZsUJDZGIi3XfUiz7KtgwZd5q+nXyouxxvR87447KXHt20XEhIYMGU3zHwV X-Received: by 10.66.155.102 with SMTP id vv6mr35023499pab.89.1395166277440; Tue, 18 Mar 2014 11:11:17 -0700 (PDT) Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id fg12sm91158754pac.28.2014.03.18.11.11.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 11:11:16 -0700 (PDT) Message-ID: <53288C43.9010205@mit.edu> Date: Tue, 18 Mar 2014 11:11:15 -0700 From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4gTUuhRa_CO44pd53sW7MYIK8do Subject: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Mar 2014 18:16:38 -0000 I'd like to see TLS 1.3 solve what I consider to be two major problems in past versions. 1. When clients authenticate with a password, if they send their password to the wrong server, that server learns their password. This is the basis of most phishing attacks. (I'm ignoring TLS-SRP, which is basically unused.) 2. If a client uses a client certificate, the client has to store the private key *and* certificate associated with the certificate. That means that any encrypted form of that certificate is subject to a dictionary attack. Both of these problems can be solved if the default mode of client authentication in TLS 1.3 were an augmented PAKE or a non-key-exchanging equivalent. #1 is addressed directly, and it would even be safe to share passwords between different servers. #2 is also solved: a client certificate could be some identifying information (which does *not* contain a PAKE verifier) and a high-entropy "password" encrypted with a real password. As long as the encryption doesn't provide a way to check whether the key is correct, no one can brute-force the client's password without a round trip to the server for each guess. It might make sense to use similar techniques to authenticate servers to clients. First, symmetry is nice. Second, I think that several of the protocols for doing this kind of authentication are actually *faster* than using digital signatures. Should TLS do something like this? This may fit in with Watson Ladd's suggestions about using something other than conventional DH for key exchange. --Andy From nobody Tue Mar 18 14:13:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0B01A023C for ; Tue, 18 Mar 2014 14:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPke0BZIyTaF for ; Tue, 18 Mar 2014 14:13:23 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3944B1A03F1 for ; Tue, 18 Mar 2014 14:13:23 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 0DED5F984; Tue, 18 Mar 2014 17:13:12 -0400 (EDT) Message-ID: <5328B6DF.8070703@fifthhorseman.net> Date: Tue, 18 Mar 2014 17:13:03 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: Andy Lutomirski , "tls@ietf.org" References: <53288C43.9010205@mit.edu> In-Reply-To: <53288C43.9010205@mit.edu> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="irkbWRAxnjKwglceEkLDn9A8ExUkbWf10" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7LrZfyDxMNMDFa0EiJokHS_DG1Y Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Mar 2014 21:13:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --irkbWRAxnjKwglceEkLDn9A8ExUkbWf10 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Andy-- Thanks for raising this question. On 03/18/2014 02:11 PM, Andy Lutomirski wrote: > 1. When clients authenticate with a password, if they send their > password to the wrong server, that server learns their password. I think you're talking about HTTP basic auth here, or IMAP AUTH=3DPLAIN, right? Other authentication mechanisms that are layered on top of TLS don't necessarily have the same concern. > This > is the basis of most phishing attacks. (I'm ignoring TLS-SRP, which is= > basically unused.) TLS SRP's lack of use suggests that there is not a high pressure for deployment here. It's probably worth thinking some about why SRP adoption has been so slow (i don't know the global answer here, but i only know a few folks who are using it) > 2. If a client uses a client certificate, the client has to store the > private key *and* certificate associated with the certificate. That > means that any encrypted form of that certificate is subject to a > dictionary attack. i'm not sure i understand. the certificate is public, right? i think you mean that the stored public key (presumably encrypted locally) is subject to an offline dictionary attack. This is no better or worse than a client with an encrypted password store, of course. A client which caches credentials for the user over the long term should be locking those credentials (whether public-key-based or password-based) with a heavily-stretched password, to make offline dictionary attacks expensive. > Both of these problems can be solved if the default mode of client > authentication in TLS 1.3 were an augmented PAKE or a non-key-exchangin= g > equivalent. #1 is addressed directly, and it would even be safe to > share passwords between different servers. how does PAKE allow sharing of passwords between servers? can't a server willing to do a bunch of offline computation figure out the client's password from its stored verifier? this moves the offline dictionary attack from the client to the server, but it would still allow the server to recover the client's password, which would then enable its reuse on different sites if the user thought it was ok to share a password between services. > It might make sense to use similar techniques to authenticate servers t= o > clients. First, symmetry is nice. Second, I think that several of the= > protocols for doing this kind of authentication are actually *faster* > than using digital signatures. how strong is a PAKE for a generic network-based adversary? how strong is it when the server itself is the adversary? At the CFRG meeting at IETF-89 earlier this month, there was very little enthusiasm in the room for further discussion about PAKE. this may just be fatigue from the dragonfly discussion, though. > Should TLS do something like this? This may fit in with Watson Ladd's > suggestions about using something other than conventional DH for key > exchange. What about this proposal is different from SRP, which we already have? Why not encourage more adoption of SRP and learn what the sticking points are for that authentication mechanism? My basic sense is that PAKE models are generally useful for one-shot or limited-time use, as a bootstrapping step to something stronger, but not as a regular, per-connection authentication mechanism. I'd be happy to be convinced that they're more generally useful, though :) Regards, --dkg --irkbWRAxnjKwglceEkLDn9A8ExUkbWf10 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ7BAEBCgBmBQJTKLbfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcY0wP9iQjarTfhktZ3B1gfAOycOm1 +B35BlMlDyGv5LfKD/S5aE3DwO44iDddTmCMXFfndGWJ0XBbcz1+XI7EB3d+VIJy fnynDD5/FFdLDtm8M0kor1YJtMz1baF6Aro3rrzr6rCyUzOgsC0Pkkt5x0szO8ST EZGNV+9oEINfir63WKjg+OPFWWos6Ktvpy9jnlOc3JDE60N0hMsOkWES0Yr9N6UN gj5UBOBWAjC6lF1U5D+V8x0LwKRyDQnxilh4qA+pMgiGqBQylNrIW8GDRHqsy5hi YlXTZad4txzJ89f60z4ws0lBlUeL18WCnz+aWkeRNzeEotzwYCu5Aej107vC5xT2 SLV9VgRZSTnARb/kiFuYSMNfVGiceyrHPZ5QrzqFYyu8vNuJyjwFP0qdDZWSz8Nj hHAdWMLmSKFTw1dHdShvjH8Xgjo7+Ih3vWtz3RejxXW7SqbvXPW1oCVpQnz4rxBx UBE9UyVEeDolCrwKfawybSrJ5S4tVnO2m49sVf9RITVC4BG0IAqpm7vDC8922cmQ V9JxFxOqByvRheHOd1g2OLI+e+QroabQDETR+xnDi9vAv7taduvKFKopv1Bb0oO6 FYOcfHOmvZffLM/JaPJuOmMyvKBsVK9omvy7VVPZBaBj7TKlGtfoWTGN36gkMM1y tT+eRu31iJtZKPmxv/w= =06LW -----END PGP SIGNATURE----- --irkbWRAxnjKwglceEkLDn9A8ExUkbWf10-- From nobody Tue Mar 18 14:55:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1550A1A0434 for ; Tue, 18 Mar 2014 14:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, 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 hGxTSUOicbDW for ; Tue, 18 Mar 2014 14:55:32 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5F35C1A030C for ; Tue, 18 Mar 2014 14:55:32 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so7727090pdi.33 for ; Tue, 18 Mar 2014 14:55:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bzqELoZ2tCRPQMY94e+rXn8ygChIn3xVZF2Z7b+n6go=; b=AukZbwscOVFagPZ5fkj3ij2MLeDL3akoRkGbyO3bcLeqlOJs3M2CexfiJ9q/NkFbiB lMAiENwFCeWBUX1X50TdCrWpadlSvR+dGtYDHQ+/1OXawKNOMOS8n2QugJREvXorMhgF R8E52TvF/pODUcIxO7/1mk4Ie8r2XtsUeUXO/DAPp9Bt7YQ8Vu1NoxJ2OYfi/eYQJ6RL 5na2GNLGOYib0aEN1fP/Qj19Fn85YqbHk+miCN2rz9sAab3XlwDu58p1ku5HRMFehtYE TmZEuRSvyAX/NaLEAA0uEkoOo/eICr41yhjroz5Ax6dlBLizMoeUV4C/kv7vPISIs2PW d9BQ== X-Gm-Message-State: ALoCoQmU/+BB4+dJtSPdNWya7inTbmEX4MXgOqoeGIZuOPYxQiDwUQ9bjTq5ldthhAx40nCCMkuR X-Received: by 10.66.176.143 with SMTP id ci15mr36208260pac.35.1395179723984; Tue, 18 Mar 2014 14:55:23 -0700 (PDT) Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id xn10sm93430632pab.0.2014.03.18.14.55.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 14:55:22 -0700 (PDT) Message-ID: <5328C0C8.9060403@mit.edu> Date: Tue, 18 Mar 2014 14:55:20 -0700 From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Andy Lutomirski , "tls@ietf.org" References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> In-Reply-To: <5328B6DF.8070703@fifthhorseman.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cOk42t11XkhPdc-bFXRi-qQKIM4 Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Mar 2014 21:55:36 -0000 On 03/18/2014 02:13 PM, Daniel Kahn Gillmor wrote: > > Hi Andy-- > > Thanks for raising this question. > > On 03/18/2014 02:11 PM, Andy Lutomirski wrote: >> 1. When clients authenticate with a password, if they send their >> password to the wrong server, that server learns their password. > > I think you're talking about HTTP basic auth here, or IMAP AUTH=PLAIN, > right? Other authentication mechanisms that are layered on top of TLS > don't necessarily have the same concern. As far as I know, pretty much all authentication methods that layer on top of TLS either have this problem or are, at the very least, vulnerable to dictionary attack by a rogue server. Getting secure augmented password-based authentication right is tricky, and I think that TLS should offer this service. > >> This >> is the basis of most phishing attacks. (I'm ignoring TLS-SRP, which is >> basically unused.) > > TLS SRP's lack of use suggests that there is not a high pressure for > deployment here. > > It's probably worth thinking some about why SRP adoption has been so > slow (i don't know the global answer here, but i only know a few folks > who are using it) I'd guess it's a chicken-and-egg problem. > >> 2. If a client uses a client certificate, the client has to store the >> private key *and* certificate associated with the certificate. That >> means that any encrypted form of that certificate is subject to a >> dictionary attack. > > i'm not sure i understand. the certificate is public, right? i think > you mean that the stored public key (presumably encrypted locally) is > subject to an offline dictionary attack. This is no better or worse > than a client with an encrypted password store, of course. There are several ways to make this work. For example, suppose that a server or organization wants to accept client certificates. It issues to each client c some identifier I_c that identifies that client and a randomly generated augmented PAKE "password" P_c. The issuer remembers V_c (the verifier corresponding to P_c) for each client. The issuer and all of the servers need to be able to look up (or decrypt) V_c given I_c, but, critically, the client must store a copy of V_c or anything that can be used to generate V_c. The client chooses a password and stores (I_c, E_password(P_c)). E should be a pseudorandom permutation keyed by the password. Now, if the client's encrypted key is stolen, an attacker cannot mount an offline dictionary attack to recover the low-entropy password. With TLS client authentication as it currently stands, I think it's basically impossible to achieve this type of security. The goal is to achieve "Type III" security in [1]. > > A client which caches credentials for the user over the long term should > be locking those credentials (whether public-key-based or > password-based) with a heavily-stretched password, to make offline > dictionary attacks expensive. > >> Both of these problems can be solved if the default mode of client >> authentication in TLS 1.3 were an augmented PAKE or a non-key-exchanging >> equivalent. #1 is addressed directly, and it would even be safe to >> share passwords between different servers. > > how does PAKE allow sharing of passwords between servers? can't a > server willing to do a bunch of offline computation figure out the > client's password from its stored verifier? this moves the offline > dictionary attack from the client to the server, but it would still > allow the server to recover the client's password, which would then > enable its reuse on different sites if the user thought it was ok to > share a password between services. Yes, this is true, of course. It's still an improvement over the status quo, where a dictionary attack isn't even needed. > >> It might make sense to use similar techniques to authenticate servers to >> clients. First, symmetry is nice. Second, I think that several of the >> protocols for doing this kind of authentication are actually *faster* >> than using digital signatures. > > how strong is a PAKE for a generic network-based adversary? how strong > is it when the server itself is the adversary? > > At the CFRG meeting at IETF-89 earlier this month, there was very little > enthusiasm in the room for further discussion about PAKE. this may just > be fatigue from the dragonfly discussion, though. > >> Should TLS do something like this? This may fit in with Watson Ladd's >> suggestions about using something other than conventional DH for key >> exchange. > > What about this proposal is different from SRP, which we already have? > Why not encourage more adoption of SRP and learn what the sticking > points are for that authentication mechanism? SRP is a complicated and rather slow thing that bolts on to TLS pre-1.3. Since the whole key exchange concept is being rethought for TLS 1.3 (or is at least apparently up for discussion), it may be possible to have TLS 1.3's standard key exchange be directly usable as an augmented PAKE without any significant drawbacks. I'll leave the details to the more serious cryptographers, but I suspect that triple DH could actually be made to work: rather than having Alice send (g^a, g^x), she sends ("Alice", g^x) and lets Bob look up / decrypt g^a on his own. If TLS 1.3 naturally supported augmented PAKE-style authentication, then using it as as simple as setting the credentials. This is a far cry from the current state of affairs, which involves using arcane and barely supported APIs in the various awful TLS implementations to try to get SRP to work and hoping it doesn't kill performance. > > My basic sense is that PAKE models are generally useful for one-shot or > limited-time use, as a bootstrapping step to something stronger, but not > as a regular, per-connection authentication mechanism. I'd be happy to > be convinced that they're more generally useful, though :) I think that there's no real downside to using PAKE for all or almost all authentication, not just passwords. After all, authenticating with a traditional keypair just means that you prove to your peer that you know a private key that corresponds to a public key known by the peer. Authenticating with an augmented PAKE is exactly the same thing, with the added properties that offline dictionary attacks are impossible (at least against low-entropy passwords) and that the private key can be an arbitrary string. [1] http://eprint.iacr.org/2012/120.pdf From nobody Tue Mar 18 22:55:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAD11A04B4 for ; Tue, 18 Mar 2014 22:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6, SPF_FAIL=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 NRJ0ju1R9pkl for ; Tue, 18 Mar 2014 22:54:57 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (agjbgdcfdbgc.dreamhost.com [69.163.253.162]) by ietfa.amsl.com (Postfix) with ESMTP id B3D2F1A04A6 for ; Tue, 18 Mar 2014 22:54:57 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 2E51A584057; Tue, 18 Mar 2014 22:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=mIf7aDytGchrE1/aC9mDsaHc9gM=; b=VR82ZBNntFuM4vlL7 TkmhXHa5a3kTop+N44ESB5kkVkhg13kUbX3f6Ic09psgb4m7N6QXUMu9oef+FHNk F07qqrq84w3ekLWVc4Rttq3fc9y2gdm6it5TtZAU2pi2bwGQfsCWM56qoKAJjJUZ KvR0mO/d4z20z+JhhdDuGapcMc= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPA id E8EA5584056; Tue, 18 Mar 2014 22:54:48 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 18 Mar 2014 22:54:49 -0700 Message-ID: <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> In-Reply-To: <5328C0C8.9060403@mit.edu> References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> Date: Tue, 18 Mar 2014 22:54:49 -0700 From: "Ryan Sleevi" To: "Andy Lutomirski" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TVZAC0Q6tkBE0sZKZkUvH7z16Sw Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 05:54:59 -0000 On Tue, March 18, 2014 2:55 pm, Andy Lutomirski wrote: > On 03/18/2014 02:13 PM, Daniel Kahn Gillmor wrote: > > > > Hi Andy-- > > > > Thanks for raising this question. > > > > On 03/18/2014 02:11 PM, Andy Lutomirski wrote: > >> 1. When clients authenticate with a password, if they send their > >> password to the wrong server, that server learns their password. > > > > I think you're talking about HTTP basic auth here, or IMAP AUTH=3DPLA= IN, > > right? Other authentication mechanisms that are layered on top of TL= S > > don't necessarily have the same concern. > > As far as I know, pretty much all authentication methods that layer on > top of TLS either have this problem or are, at the very least, > vulnerable to dictionary attack by a rogue server. Getting secure > augmented password-based authentication right is tricky, and I think > that TLS should offer this service. > > > > >> This > >> is the basis of most phishing attacks. (I'm ignoring TLS-SRP, which= is > >> basically unused.) Since you raised "phishing" as your concern, I'm entirely responding within the context that you're talking about user-facing actions within the context of a web browser. I have yet to hear of a good mail client "phishing" attack (you *are* validating your IMAP certs, right?), so this seems almost predominantly an issue of attacker-controlled UI - that is, the web. > > > > TLS SRP's lack of use suggests that there is not a high pressure for > > deployment here. > > > > It's probably worth thinking some about why SRP adoption has been so > > slow (i don't know the global answer here, but i only know a few folk= s > > who are using it) > > I'd guess it's a chicken-and-egg problem. No. It's really not. It's a usability problem, and one that doesn't get solved easily. It's not unique to TLS-SRP. It's just as applicable to TLS client certificates. Browsers don't want it: - It requires the browser implement a special (trusted) UI, since by definition, it's the browser's responsibility to terminate TLS connections. Sites don't want it: - Sites don't want to force browser UI on their users, they want to control and customize the UI. They want to handle failures, not rely on browsers that may or may not handle errors in the manner in which they desire. Users don't want it: - Users *like* sites' form-based authentication. It integrates easily wit= h their mental model, provides easy avenues for trouble-shooting ("forgot m= y password", etc). This is the exact same problem with client certificates. Both solutions (TLS-SRP and client cert auth) are trying to solve application auth issues at the transport. This doesn't work well. Heck, even GSSAPI doesn't have a good solution for this when authenticating to sites with SPNEGO (although the ongoing work for cred UI is exciting stuff). The real drive - of sites and of browsers - is trying to find ways to giv= e sites as much control of the UI as possible, while simultaneously reducin= g the risk - of password breaches and security incidents. If you want to se= e the practical efforts to "solve" the phishing problem, look at stuff like http://fidoalliance.org/ There are still be opportunities to improve things within TLS - channel bindings being the most obvious issue at hand. Sites - and browsers - want assurances similar to client certs, but without all of the countless headaches (eg: Define a reasonable way to "Log Out" in the case of CCA when talking to a website, where you may hav= e N parallel connections, which may have Y TLS sessions depending on timing= , and which have a whole host of internal state full of spit-and-glue just trying to make CCA semi-usable for HTTP) I'm hard-pressed to find a use case for TLS-SRP in the context of the web= , nor do we hear sites really clamoring for it, and an augmented PAKE is just same story, different day. If you're talking outside the context of the web, then maybe there's a us= e case, but my instinct is "meh". I think you'll be hard pressed to find anyone who really loves passwords or thinks we should encourage more of them. From nobody Wed Mar 19 08:43:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904DC1A0442 for ; Wed, 19 Mar 2014 08:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZQ-gQ-6o7bM for ; Wed, 19 Mar 2014 08:43:48 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 883671A06B2 for ; Wed, 19 Mar 2014 08:43:48 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id cz12so9122152veb.35 for ; Wed, 19 Mar 2014 08:43:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4TeNaPVaQJ7Bdt69JFZVMi8WsV5jV+mFQzFVpXtx7W0=; b=GH9Iy/im/4PImvE8tlpuLe7tm6kk24jCTMiLJEpy3CQratsv5LVFZni6gbOCUHVbAy JgRksjW1UK7GhUg45dwv/HbWX+sIfCuavlfw4GHeYJZGAPIRvDcKcVPqVaNoWlbbYSnd +dqIz1Hq39zlw77udlRKKGKYsTm7CdxF00MGpmkI7AxPsZVByRN5j/j4QPbpIzt72mo4 2AoYcGWjGAxFsSHnUUHBIk0PqZGRN6+zpQX3NxGtPqaMHjvxYQxo1HqShaC+QzIoMadj jmW+Nrl4Zu3Qw4JmPIqtqB4tfEvqVwjPpxo4SX8ZnrC0Cti7uVuaHmv83sdCh+eBx21j Je/w== X-Gm-Message-State: ALoCoQn52ebvTtt6qzb1DFMKtE2fPCFN2OM4x3K8jVO9RbzROBeAw7zQwHuA3oYQ8pry0pocFaYT X-Received: by 10.52.50.178 with SMTP id d18mr100770vdo.53.1395243819748; Wed, 19 Mar 2014 08:43:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.83.130 with HTTP; Wed, 19 Mar 2014 08:43:19 -0700 (PDT) In-Reply-To: <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> From: Andy Lutomirski Date: Wed, 19 Mar 2014 08:43:19 -0700 Message-ID: To: ryan-ietftls@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/i-lwqAs9sVelvpwAdxFK9iHVq5g Cc: "tls@ietf.org" Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Mar 2014 15:43:50 -0000 On Tue, Mar 18, 2014 at 10:54 PM, Ryan Sleevi wrote: > On Tue, March 18, 2014 2:55 pm, Andy Lutomirski wrote: >> On 03/18/2014 02:13 PM, Daniel Kahn Gillmor wrote: >> > >> > Hi Andy-- >> > >> > Thanks for raising this question. >> > >> > On 03/18/2014 02:11 PM, Andy Lutomirski wrote: >> >> 1. When clients authenticate with a password, if they send their >> >> password to the wrong server, that server learns their password. >> > >> > I think you're talking about HTTP basic auth here, or IMAP AUTH=PLAIN, >> > right? Other authentication mechanisms that are layered on top of TLS >> > don't necessarily have the same concern. >> >> As far as I know, pretty much all authentication methods that layer on >> top of TLS either have this problem or are, at the very least, >> vulnerable to dictionary attack by a rogue server. Getting secure >> augmented password-based authentication right is tricky, and I think >> that TLS should offer this service. >> >> > >> >> This >> >> is the basis of most phishing attacks. (I'm ignoring TLS-SRP, which is >> >> basically unused.) > > Since you raised "phishing" as your concern, I'm entirely responding > within the context that you're talking about user-facing actions within > the context of a web browser. I have yet to hear of a good mail client > "phishing" attack (you *are* validating your IMAP certs, right?), so this > seems almost predominantly an issue of attacker-controlled UI - that is, > the web. > >> > >> > TLS SRP's lack of use suggests that there is not a high pressure for >> > deployment here. >> > >> > It's probably worth thinking some about why SRP adoption has been so >> > slow (i don't know the global answer here, but i only know a few folks >> > who are using it) >> >> I'd guess it's a chicken-and-egg problem. > > No. It's really not. It's a usability problem, and one that doesn't get > solved easily. > > It's not unique to TLS-SRP. It's just as applicable to TLS client > certificates. > > Browsers don't want it: > - It requires the browser implement a special (trusted) UI, since by > definition, it's the browser's responsibility to terminate TLS > connections. I think that browsers should do *exactly* this. There's already one for the lock icon -- adding one for password entry seems like a natural extension. Even better: users who use such a thing don't need to be nearly as careful about checking the actual URL before entering their password. > > Sites don't want it: > - Sites don't want to force browser UI on their users, they want to > control and customize the UI. They want to handle failures, not rely on > browsers that may or may not handle errors in the manner in which they > desire. This can be fixed. > > Users don't want it: > - Users *like* sites' form-based authentication. It integrates easily with > their mental model, provides easy avenues for trouble-shooting ("forgot my > password", etc). You're assuming that an augmented PAKE with a trusted UI can't do all of that. If a website could request a zero-knowledge proof of knowledge of a secret, where the secret has this description next to it and this set of extra buttons (the buttons would be plain links and would *not* transmit the password), I think that everyone wins. Heck, the whole trusted dialog could be written in HTML and, as long as the ability to submit forms were restricted and scripts were blocked, it should just work. Admittedly, this doesn't really fit in to my suggestion of doing it as part of TLS key exchange. > > This is the exact same problem with client certificates. > > Both solutions (TLS-SRP and client cert auth) are trying to solve > application auth issues at the transport. This doesn't work well. Heck, > even GSSAPI doesn't have a good solution for this when authenticating to > sites with SPNEGO (although the ongoing work for cred UI is exciting > stuff). > > The real drive - of sites and of browsers - is trying to find ways to give > sites as much control of the UI as possible, while simultaneously reducing > the risk - of password breaches and security incidents. If you want to see > the practical efforts to "solve" the phishing problem, look at stuff like > http://fidoalliance.org/ That was actually my inspiration for suggesting this feature. Suppose you use a second factor (e.g. Fido U2F) device to authenticate to your bank. You've set a PIN "1234". An attacker subsequently steals your U2F device. If the device is well designed, locks out the key after a few tries, is suitably slow rejecting bad PINs, and is truly tamper proof, then everything is OK. But that's a big if. The problem is that using ECDSA signatures or anything like then in a second factor is the wrong approach, I think. If a second factor instead answered an augmented PAKE challenge, it could be implemented in such a way that it wouldn't be able to distinguish a correct PIN from an incorrect PIN. Then the server could lock out the account after a few tries, and an attacker wouldn't be able to usefully attack the device even if they completely broke its tamper protection. This is mostly outside the scope of the TLS WG, but I think that TLS could do a lot to make this kind of thing easier. --Andy From nobody Wed Mar 19 09:06:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72AE11A07A0 for ; Wed, 19 Mar 2014 09:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PT1iDN5QNT-X for ; Wed, 19 Mar 2014 09:06:52 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id EF9FD1A0790 for ; Wed, 19 Mar 2014 09:06:51 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id cz12so9160584veb.35 for ; Wed, 19 Mar 2014 09:06:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Te3Ugzou6DoynDhOmGvQIczxwghnuCK96Y/nWgKvau8=; b=YfRydFNnC6P62J6mXusPskWUpn+T114WbjCSqMTqEIaDezB3pBHfgAzkCAxYNAJhxE yFD/H/MVahFCxTReC3fymRultSt2pF9D0h3z4mn6nAaj4KZGgKAvCy3F0GypGqN8Zyhu hRsNvEGnXeCzLQ0uSr1fisldnWaGNH87B4vnhSYe1Qb340H88cwmYi+UT00A083SHXMy lBvBUoKhQXuO4xTDBg4FpYH3xb6nQMcGiiNHwU5D0/GpEBk3d5fPR1pRrQrno308ylDR WZuYEYqP1mSipbNKhPhCHATa/GeqnPoddFZfKCNjLwaTOBuAwzHkb22XT5n0dkHgNSUa lq9w== X-Gm-Message-State: ALoCoQkk1jW9dNuvTLPzQG/ZCMst7b/CPtQFYDBcsPUID3n0Gr6fye9o0f+KM0ueGMK6k/gFPBa/ X-Received: by 10.52.51.226 with SMTP id n2mr6140vdo.57.1395245203160; Wed, 19 Mar 2014 09:06:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.83.130 with HTTP; Wed, 19 Mar 2014 09:06:23 -0700 (PDT) In-Reply-To: <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> From: Andy Lutomirski Date: Wed, 19 Mar 2014 09:06:23 -0700 Message-ID: To: ryan-ietftls@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Dl96oGI9PLmDFkCXarTov-l2EKs Cc: "tls@ietf.org" Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Mar 2014 16:06:53 -0000 On Tue, Mar 18, 2014 at 10:54 PM, Ryan Sleevi wrote: > I have yet to hear of a good mail client > "phishing" attack (you *are* validating your IMAP certs, right?), so this > seems almost predominantly an issue of attacker-controlled UI - that is, > the web. Even for IMAP, using PAKE, augmented or balanced, would give a significant amount of protection against MITMs who have compromised a CA. Since compromising a CA seems to be a popular thing to do these days, resisting these attacks at the protocol level would add considerable value. --Andy From nobody Wed Mar 19 09:10:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD6C1A07B9 for ; Wed, 19 Mar 2014 09:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 ZhDMofz8MJL6 for ; Wed, 19 Mar 2014 09:09:52 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECD31A07C1 for ; Wed, 19 Mar 2014 09:09:52 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s2JG9fUI002465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 19 Mar 2014 11:09:43 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s2JG9bNr031717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 19 Mar 2014 17:09:41 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.116]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 19 Mar 2014 17:09:40 +0100 From: "Schwarz, Albrecht (Albrecht)" To: "TLS@ietf.org" Thread-Topic: TLS 1.3: Enhanced definitions of terms "TLS session" and "TLS connection" Thread-Index: Ac9DjZ+ZjmG0vyWtSwSda/q5qX0LqA== Date: Wed, 19 Mar 2014 16:09:39 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC1B5B78@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6nauogQr3IGXuMHA25ntj3H8b4A Subject: [TLS] TLS 1.3: Enhanced definitions of terms "TLS session" and "TLS connection" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Mar 2014 16:09:55 -0000 Dear All, like to raise a question related to the RFC 5246, Appendix B "Glossary": Status:=20 - connection:=09 A connection is a transport (in the OSI layering model definition) t= hat provides a suitable type of service. For TLS, such connections are pee= r-to-peer relationships. The connections are transient. Every connection = is associated with one session. - session:=09 A TLS session is an association between a client and a server. Sessi= ons are created by the handshake protocol. Sessions define a set of crypto= graphic security parameters that can be shared among multiple connections. = Sessions are used to avoid the expensive negotiation of new security param= eters for each connection. Both terms are rather high-level and silent concerning a number of key char= acteristics. E.g., What constitutes exactly a "TLS session"? Just the 1-tuple of a "session id= " or the 6-tuple of {session identifier, peer certificate, compression meth= od, cipher spec, master secret, is resumable}" (based on clause 7/RFC 5246)= ? Similar, what constitues exactly a "TLS connection"? An n-tuple based on th= e ConnectionState on clause 6.1/RFC 5246, just a sub-set ..., the 5-tuple o= f IP transport connection endpoint addresses? What exactly is the relation between a "TLS session" and its associated "TL= S connection(s)"? Resumption of a "TLS session"? What kind of "data object (configuration)" i= s exactly used as starting point for the "resumption procedure"? Such kind of questions are all leading to the baseline of good terminology.= The existing Glossary could and should be improved in my understanding. Any opinions, comments from TLS expert side? Anyone aware of similar terminology enhancements requests in the past? Thanks, Albrecht From nobody Wed Mar 19 09:13:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810901A07C3 for ; Wed, 19 Mar 2014 09:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_FAIL=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 8NQ69X9ELKNZ for ; Wed, 19 Mar 2014 09:13:04 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (agjbgdcfdbgc.dreamhost.com [69.163.253.162]) by ietfa.amsl.com (Postfix) with ESMTP id C7C1E1A07C1 for ; Wed, 19 Mar 2014 09:13:04 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 4260C5840F7; Wed, 19 Mar 2014 09:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=AE09v+aZl5OX86P0W9Gx6j1zCBg=; b=r9twFwLFx1UfjARjf pOLtWUoVheso6w0xsSrI7geDrcXwDDTEYEOfEefWdHunKEumVH0KJKNSbxuYOtwp 9BrplvHnPrpPR0RrWEnzrotVBjhicZPLNrpPTNWw8P5eQ5C3qij5PllOSObJbnfG 197IeDILIjC5rLMgxDBPoGJcco= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPA id E98BD5840CA; Wed, 19 Mar 2014 09:12:55 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 19 Mar 2014 09:12:56 -0700 Message-ID: <8add91ddc18f9364408651327523c891.squirrel@webmail.dreamhost.com> In-Reply-To: References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> Date: Wed, 19 Mar 2014 09:12:56 -0700 From: "Ryan Sleevi" To: "Andy Lutomirski" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kuVLI_4Zhr8GyeceZDTnprFhZP0 Cc: "tls@ietf.org" Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 16:13:06 -0000 On Wed, March 19, 2014 8:43 am, Andy Lutomirski wrote: > On Tue, Mar 18, 2014 at 10:54 PM, Ryan Sleevi > wrote: > > On Tue, March 18, 2014 2:55 pm, Andy Lutomirski wrote: [Snip] > >> I'd guess it's a chicken-and-egg problem. > > > > No. It's really not. It's a usability problem, and one that doesn't g= et > > solved easily. > > > > It's not unique to TLS-SRP. It's just as applicable to TLS client > > certificates. > > > > Browsers don't want it: > > - It requires the browser implement a special (trusted) UI, since by > > definition, it's the browser's responsibility to terminate TLS > > connections. > > I think that browsers should do *exactly* this. There's already one > for the lock icon -- adding one for password entry seems like a > natural extension. Even better: users who use such a thing don't need > to be nearly as careful about checking the actual URL before entering > their password. Challenge: Go find a site using HTTP auth (of any form - BASIC, DIGEST, etc), that wasn't built in the 1990s or a slow-moving SDO. Ask them how they like it. Answer: They don't. No site wants to use browser UI. It's a bad UX. > > > > > Sites don't want it: > > - Sites don't want to force browser UI on their users, they want to > > control and customize the UI. They want to handle failures, not rely = on > > browsers that may or may not handle errors in the manner in which the= y > > desire. > > This can be fixed. And the ocean can be boiled to power a giant steam engine. These are both true statements, but both discount the huge efforts for the minimal gains and real harm possible. > > > > > Users don't want it: > > - Users *like* sites' form-based authentication. It integrates easily > > with > > their mental model, provides easy avenues for trouble-shooting ("forg= ot > > my > > password", etc). > > You're assuming that an augmented PAKE with a trusted UI can't do all > of that. If a website could request a zero-knowledge proof of > knowledge of a secret, where the secret has this description next to > it and this set of extra buttons (the buttons would be plain links and > would *not* transmit the password), I think that everyone wins. Heck, > the whole trusted dialog could be written in HTML and, as long as the > ability to submit forms were restricted and scripts were blocked, it > should just work. > > Admittedly, this doesn't really fit in to my suggestion of doing it as > part of TLS key exchange. Which was exactly my point. > > > > > This is the exact same problem with client certificates. > > > > Both solutions (TLS-SRP and client cert auth) are trying to solve > > application auth issues at the transport. This doesn't work well. Hec= k, > > even GSSAPI doesn't have a good solution for this when authenticating= to > > sites with SPNEGO (although the ongoing work for cred UI is exciting > > stuff). > > > > The real drive - of sites and of browsers - is trying to find ways to > > give > > sites as much control of the UI as possible, while simultaneously > > reducing > > the risk - of password breaches and security incidents. If you want t= o > > see > > the practical efforts to "solve" the phishing problem, look at stuff > > like > > http://fidoalliance.org/ > > That was actually my inspiration for suggesting this feature. Suppose > you use a second factor (e.g. Fido U2F) device to authenticate to your > bank. You've set a PIN "1234". An attacker subsequently steals your > U2F device. > > If the device is well designed, locks out the key after a few tries, > is suitably slow rejecting bad PINs, and is truly tamper proof, then > everything is OK. But that's a big if. > > The problem is that using ECDSA signatures or anything like then in a > second factor is the wrong approach, I think. If a second factor > instead answered an augmented PAKE challenge, it could be implemented > in such a way that it wouldn't be able to distinguish a correct PIN > from an incorrect PIN. Then the server could lock out the account > after a few tries, and an attacker wouldn't be able to usefully attack > the device even if they completely broke its tamper protection. > > This is mostly outside the scope of the TLS WG, but I think that TLS > could do a lot to make this kind of thing easier. > > --Andy > It's not a technological issue. It's a social/usability issue. And the TLS WG is, arguably, one of the least suited of all WGs to solve this. From nobody Wed Mar 19 09:17:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51D11A0705 for ; Wed, 19 Mar 2014 09:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_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 99FQ7RV8w3ez for ; Wed, 19 Mar 2014 09:17:17 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id D47A61A06F7 for ; Wed, 19 Mar 2014 09:17:16 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hm4so5090771wib.2 for ; Wed, 19 Mar 2014 09:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vjDkQmrwRv1AICCEQuasjZzg0aY2FKTA4wp4ZLA/vBQ=; b=09Ic9bU0AygUaDNIIIgvejhIRnHhozEehdAR75b0t8uLeSNO/Q4jrlMVSWuEYoPG3G mttKqU9fZWQ1LuSkFw22QaKBFjyAd0Xg6uRz2JxDQjywcwQHPkLCdC/AMthGcXKGr0M2 Dypq8vcKpTxswU8mHwVjDTiVrtQVVVavHgl5wLvhC52KZ5MrfctjS4ZKa5eOmY7LoIBM SM5XHAEZi0Pj08JULrmaEwzQUgg1+cPLmE3JXLojuc3LT5bO5IxtA0MiEAlfXo0jV4GW qFwxeChwycHxYzgpb4yhAZGJwT1X8cPM3loCxYtPFSWE53zNR3BlhxHMkQaJIb472N+z EwEQ== X-Received: by 10.194.120.101 with SMTP id lb5mr2648734wjb.74.1395245827682; Wed, 19 Mar 2014 09:17:07 -0700 (PDT) Received: from [192.168.1.99] (188.110.176.95.rev.sfr.net. [95.176.110.188]) by mx.google.com with ESMTPSA id fq16sm57151914wjc.3.2014.03.19.09.17.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 09:17:06 -0700 (PDT) Message-ID: <5329C2FD.2040909@gmail.com> Date: Wed, 19 Mar 2014 17:17:01 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Andy Lutomirski References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rXVh42C0suwFN1vqZzYSDdLHBuE Cc: "tls@ietf.org" Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Mar 2014 16:17:19 -0000 On 2014-03-19 16:43, Andy Lutomirski wrote: > On Tue, Mar 18, 2014 at 10:54 PM, Ryan Sleevi wrote: >> On Tue, March 18, 2014 2:55 pm, Andy Lutomirski wrote: >>> On 03/18/2014 02:13 PM, Daniel Kahn Gillmor wrote: >>>> >>>> Hi Andy-- >>>> >>>> Thanks for raising this question. >>>> >>>> On 03/18/2014 02:11 PM, Andy Lutomirski wrote: >>>>> 1. When clients authenticate with a password, if they send their >>>>> password to the wrong server, that server learns their password. >>>> >>>> I think you're talking about HTTP basic auth here, or IMAP AUTH=PLAIN, >>>> right? Other authentication mechanisms that are layered on top of TLS >>>> don't necessarily have the same concern. >>> >>> As far as I know, pretty much all authentication methods that layer on >>> top of TLS either have this problem or are, at the very least, >>> vulnerable to dictionary attack by a rogue server. Getting secure >>> augmented password-based authentication right is tricky, and I think >>> that TLS should offer this service. >>> >>>> >>>>> This >>>>> is the basis of most phishing attacks. (I'm ignoring TLS-SRP, which is >>>>> basically unused.) >> >> Since you raised "phishing" as your concern, I'm entirely responding >> within the context that you're talking about user-facing actions within >> the context of a web browser. I have yet to hear of a good mail client >> "phishing" attack (you *are* validating your IMAP certs, right?), so this >> seems almost predominantly an issue of attacker-controlled UI - that is, >> the web. >> >>>> >>>> TLS SRP's lack of use suggests that there is not a high pressure for >>>> deployment here. >>>> >>>> It's probably worth thinking some about why SRP adoption has been so >>>> slow (i don't know the global answer here, but i only know a few folks >>>> who are using it) >>> >>> I'd guess it's a chicken-and-egg problem. >> >> No. It's really not. It's a usability problem, and one that doesn't get >> solved easily. >> >> It's not unique to TLS-SRP. It's just as applicable to TLS client >> certificates. >> >> Browsers don't want it: >> - It requires the browser implement a special (trusted) UI, since by >> definition, it's the browser's responsibility to terminate TLS >> connections. > > I think that browsers should do *exactly* this. There's already one > for the lock icon -- adding one for password entry seems like a > natural extension. Even better: users who use such a thing don't need > to be nearly as careful about checking the actual URL before entering > their password. You want something like this? https://communities.intel.com/community/itpeernetwork/vproexpert/blog/2012/05/18/intel-ipt-with-embedded-pki-and-protected-transaction-display Petty yucky stuff IMO. Anders > >> >> Sites don't want it: >> - Sites don't want to force browser UI on their users, they want to >> control and customize the UI. They want to handle failures, not rely on >> browsers that may or may not handle errors in the manner in which they >> desire. > > This can be fixed. > >> >> Users don't want it: >> - Users *like* sites' form-based authentication. It integrates easily with >> their mental model, provides easy avenues for trouble-shooting ("forgot my >> password", etc). > > You're assuming that an augmented PAKE with a trusted UI can't do all > of that. If a website could request a zero-knowledge proof of > knowledge of a secret, where the secret has this description next to > it and this set of extra buttons (the buttons would be plain links and > would *not* transmit the password), I think that everyone wins. Heck, > the whole trusted dialog could be written in HTML and, as long as the > ability to submit forms were restricted and scripts were blocked, it > should just work. > > Admittedly, this doesn't really fit in to my suggestion of doing it as > part of TLS key exchange. > >> >> This is the exact same problem with client certificates. >> >> Both solutions (TLS-SRP and client cert auth) are trying to solve >> application auth issues at the transport. This doesn't work well. Heck, >> even GSSAPI doesn't have a good solution for this when authenticating to >> sites with SPNEGO (although the ongoing work for cred UI is exciting >> stuff). >> >> The real drive - of sites and of browsers - is trying to find ways to give >> sites as much control of the UI as possible, while simultaneously reducing >> the risk - of password breaches and security incidents. If you want to see >> the practical efforts to "solve" the phishing problem, look at stuff like >> http://fidoalliance.org/ > > That was actually my inspiration for suggesting this feature. Suppose > you use a second factor (e.g. Fido U2F) device to authenticate to your > bank. You've set a PIN "1234". An attacker subsequently steals your > U2F device. > > If the device is well designed, locks out the key after a few tries, > is suitably slow rejecting bad PINs, and is truly tamper proof, then > everything is OK. But that's a big if. > > The problem is that using ECDSA signatures or anything like then in a > second factor is the wrong approach, I think. If a second factor > instead answered an augmented PAKE challenge, it could be implemented > in such a way that it wouldn't be able to distinguish a correct PIN > from an incorrect PIN. Then the server could lock out the account > after a few tries, and an attacker wouldn't be able to usefully attack > the device even if they completely broke its tamper protection. > > This is mostly outside the scope of the TLS WG, but I think that TLS > could do a lot to make this kind of thing easier. > > --Andy > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Mar 19 09:20:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B56B1A0709 for ; Wed, 19 Mar 2014 09:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_FAIL=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 WAs4_K0rJ4pu for ; Wed, 19 Mar 2014 09:20:43 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (agjbgdcfdbeb.dreamhost.com [69.163.253.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCDA1A07B2 for ; Wed, 19 Mar 2014 09:20:42 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 9E9EC20087EAF; Wed, 19 Mar 2014 09:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=yN7FzxCqC90fmnSEjBjjFxVJMaY=; b=XmEhYAJVLit14OHgA syqMYBz5DxmjD9o3OSHF/yJ53HSKlaCaOBXaab8WhzinKhpkivv0byQskHo8Fq+O we/FfJgpTQ5+wCvlTzOy41l+UjbQuhc/m1mM/BHTzwOLYvArfgV8v7tUP94DYOB+ 9Xo88KAQgsAm4uFhFcxF2y2rdw= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id 69CAB20087EAA; Wed, 19 Mar 2014 09:20:33 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 19 Mar 2014 09:20:33 -0700 Message-ID: In-Reply-To: References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> Date: Wed, 19 Mar 2014 09:20:33 -0700 From: "Ryan Sleevi" To: "Andy Lutomirski" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BWpI9R2vTra7KQvjyVLAOzbwykY Cc: "tls@ietf.org" Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 16:20:45 -0000 On Wed, March 19, 2014 9:06 am, Andy Lutomirski wrote: > On Tue, Mar 18, 2014 at 10:54 PM, Ryan Sleevi > wrote: > > I have yet to hear of a good mail client > > "phishing" attack (you *are* validating your IMAP certs, right?), so > > this > > seems almost predominantly an issue of attacker-controlled UI - that = is, > > the web. > > Even for IMAP, using PAKE, augmented or balanced, would give a > significant amount of protection against MITMs who have compromised a > CA. Since compromising a CA seems to be a popular thing to do these > days, resisting these attacks at the protocol level would add > considerable value. > > --Andy > Or use key pinning - http://tools.ietf.org/html/draft-ietf-websec-key-pin= ning Or use DANE - https://tools.ietf.org/html/rfc6698 My point is you can see on this list archives two common threads: - A desire to reduce, as much as possible, the complexity of TLS - Not a lot of fondness for another PAKE I applaud your zeal, and my hope and goal is to try to highlight that you're trying to solve the wrong problem. On the browser side, on the sit= e side, and the user side - your target demographics - no one is really saying "Aww, if only I had a PAKE! That's what my security solution needs". If you're still convinced that *this* is the thing that TLS is missing, I would only encourage you to reach out and try to first come up with a solution for "how the password gets in the browser" before trying to figure out how the browser gets it to the server. That will at least burn a decade of energy and enthusiasm. Note that the solution equally fails to meet your goals, because you will always have browsers that don't support your solution - so sites wanting to use it will still have to support 'naked' passwords. Equally, for browsers, there will always be sites that continue to support the authentication (not the least because it's part of HTML5), so they will always be phishable via downgrade attacks - not of the TLS type, but of the UX type. So your goal of providing a more secure UI is not really achievable, and where it is, it's not really secure. If that's the only justification/goal for the augmented PAKE (and your replies suggest it is), let's just save the trouble and say "meh". From nobody Wed Mar 19 09:21:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8EB1A0790 for ; Wed, 19 Mar 2014 09:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeJv1W9nOT8u for ; Wed, 19 Mar 2014 09:21:25 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0246D1A07AF for ; Wed, 19 Mar 2014 09:21:25 -0700 (PDT) Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id B262F5E03D; Wed, 19 Mar 2014 17:15:43 +0100 (CET) Received: from [127.0.0.1] (unknown [192.168.11.68]) by mx1.on-x.com (Postfix) with ESMTP id 93B2C5E00F; Wed, 19 Mar 2014 17:15:43 +0100 (CET) Message-ID: <5329C3FB.9030405@edelweb.fr> Date: Wed, 19 Mar 2014 17:21:15 +0100 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SicQ0_GEEiw58ye2bVbAnr3tMWk Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Mar 2014 16:21:27 -0000 On 03/19/2014 04:43 PM, Andy Lutomirski wrote: > On Tue, Mar 18, 2014 at 10:54 PM, Ryan Sleevi wrote: >> TLS SRP's lack of use suggests that there is not a high pressure for >> deployment here. >> >> It's probably worth thinking some about why SRP adoption has been so >> slow (i don't know the global answer here, but i only know a few folks >> who are using it) I remember that years ago, when we implemented SRP with openssl, I was thinking about the doing same in the NSS. Well, not enough time. The reason was the possibility to use the database for url/login/password - Browsers have the user/password containers tied to some host. - A browser can add the ciphersuite but no user in the clienthello if the host is not known. - If the host is known the browser can immediately provide the identity (which could be encoded as hash(user@host). - A password could also be encoded as in Steve Bellovins draft. This leaves us at the same "inconvenience" having a pop up for the "PIN" outside the html layer but at least one would not send a password to a badly authenticated site? Peter From nobody Wed Mar 19 09:38:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED7E1A07D3 for ; Wed, 19 Mar 2014 09:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rgz-_yXmYKu3 for ; Wed, 19 Mar 2014 09:38:43 -0700 (PDT) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id F19861A0412 for ; Wed, 19 Mar 2014 09:38:42 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id jw12so9392225veb.9 for ; Wed, 19 Mar 2014 09:38:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=y4jdSklpHv+h5xLAeHY3qIZIPFdU2d7emM4Epb5uGF4=; b=P/IaUFkWdcOmnBwMMMa3J37MCNsTsJmrb7H4LE78yMnfsoaP+WNqhDVU6ZVSsYDpVP sbW8kN0k3PH89zoOXjIHa9HQ//z0s1o8WZpVv/vrBTnSb+hSBdwBNcI8reZmiAFSFAAf mdXCwONgO9QpBXJmPkpBUc+s6mMhBPs0cLeeksW0SDRn08mhKqmyZIHRA94pCCW6OibI SLTbJG5dDRY0dCA2qycXuAEFn595Gu1Zh+QbFUprq7XaRbiJoW/aUw6XUQRFTLNK4LRE aHlBO5NnGsm96r/ivASmNGXNwHUxgF2tK0kCq+QN+elZmqwYYL6dNwkUVj9sHeY4GXz5 2ZZQ== X-Gm-Message-State: ALoCoQkmMoIcXzyRbP6WaDEQrqFNNjSoQ9cSMNJny6XloPrlmSv0p+TNcmBEn2Z1723mq3q05xTl X-Received: by 10.52.250.4 with SMTP id yy4mr77717vdc.56.1395247113947; Wed, 19 Mar 2014 09:38:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.83.130 with HTTP; Wed, 19 Mar 2014 09:38:13 -0700 (PDT) In-Reply-To: <5329C2FD.2040909@gmail.com> References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <5329C2FD.2040909@gmail.com> From: Andy Lutomirski Date: Wed, 19 Mar 2014 09:38:13 -0700 Message-ID: To: Anders Rundgren Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xpHKhUiZd24Tr7aQXmfVDbGIv6c Cc: "tls@ietf.org" Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Mar 2014 16:38:47 -0000 On Wed, Mar 19, 2014 at 9:17 AM, Anders Rundgren wrote: > You want something like this? > https://communities.intel.com/community/itpeernetwork/vproexpert/blog/2012/05/18/intel-ipt-with-embedded-pki-and-protected-transaction-display > > Petty yucky stuff IMO. My copy of Thunderbird already has a perfectly usable password prompt. For applications like that, no password prompt change whatsoever would be needed -- Thunderbird would just need to know which IMAP servers use PAKE. (This might be very easy -- Thunderbird already autoconfigures for various providers.) --Andy From nobody Wed Mar 19 09:45:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934D91A07B4 for ; Wed, 19 Mar 2014 09:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttjr04gNzTvm for ; Wed, 19 Mar 2014 09:45:42 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCE91A0784 for ; Wed, 19 Mar 2014 09:45:42 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id la4so9367644vcb.17 for ; Wed, 19 Mar 2014 09:45:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6EzjZIDxnSwNi+e5UPU3t4TLWyj5cPabTb9IjIxZ0mM=; b=bXMkoxXgxZxbHjjih7VNDfkvA5qrUMWjr/YIWLozWkIVeIYVD6Cxb03/J4/Rsa3i6C ueIn7HORxfu4trULkrDCbsyhYNAn7xdLhRLcLw1Q+moQLZIjwFtIBpaVQGTWS+KN3Vs/ F9dtNAopk3kGOeou80zZEIogyuTOPqWi1K0hXP7gHqSqtJDUhNBmfr/3HfdNvQsubK58 2xB3FiacIxpS2kaDnFU1eaOueJT9Ds8Hh7x3WDM6Zi98T9ozijrwJX0IzS+2IMj1N5mI 6n83Eod9sIW5Zd48ELNXlUxzTOWaaaCGn1HQc069zIIrDaBWSCdmK2ygfZLsinbeALNE Ts2g== X-Gm-Message-State: ALoCoQm5r4ihPl2Uc+JI9VdczCekNr079L5jnwRdQ5RJpFXTVF+3Zqrvp7gmlL0C16nmk6s8B3YK X-Received: by 10.58.221.102 with SMTP id qd6mr115829vec.47.1395247533368; Wed, 19 Mar 2014 09:45:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.83.130 with HTTP; Wed, 19 Mar 2014 09:45:13 -0700 (PDT) In-Reply-To: References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> From: Andy Lutomirski Date: Wed, 19 Mar 2014 09:45:13 -0700 Message-ID: To: ryan-ietftls@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Git_HT1ClBDPSBIqnjnNtf-IfYU Cc: "tls@ietf.org" Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Mar 2014 16:45:44 -0000 On Wed, Mar 19, 2014 at 9:20 AM, Ryan Sleevi wrote: > On Wed, March 19, 2014 9:06 am, Andy Lutomirski wrote: >> On Tue, Mar 18, 2014 at 10:54 PM, Ryan Sleevi >> wrote: >> > I have yet to hear of a good mail client >> > "phishing" attack (you *are* validating your IMAP certs, right?), so >> > this >> > seems almost predominantly an issue of attacker-controlled UI - that is, >> > the web. >> >> Even for IMAP, using PAKE, augmented or balanced, would give a >> significant amount of protection against MITMs who have compromised a >> CA. Since compromising a CA seems to be a popular thing to do these >> days, resisting these attacks at the protocol level would add >> considerable value. >> >> --Andy >> > > Or use key pinning - http://tools.ietf.org/html/draft-ietf-websec-key-pinning It works, but not the first time and it's tricky to do safely from the server's POV. > > Or use DANE - https://tools.ietf.org/html/rfc6698 I've never seen anything resembling a usable implementation of DANE. It needs a way to pull a whole DNSSEC signature chain from a DNS server (barely supported with current software -- the CD flag can do it, but client code doesn't seem to support that well) or using a nonexistent TLS extension. > > My point is you can see on this list archives two common threads: > - A desire to reduce, as much as possible, the complexity of TLS > - Not a lot of fondness for another PAKE > The only reason I think my suggestion is reasonable is that I think that it could be very simple -- the main TLS key exchange be designed to have all of the necessary cryptographic properties to be an augmented PAKE. People who don't want to use it can specify null passwords. [...] > > Note that the solution equally fails to meet your goals, because you will > always have browsers that don't support your solution - so sites wanting > to use it will still have to support 'naked' passwords. Equally, for > browsers, there will always be sites that continue to support the type="password"> authentication (not the least because it's part of > HTML5), so they will always be phishable via downgrade attacks - not of > the TLS type, but of the UX type. Right. And the better websites (banks?) will offer both and users will learn that, when they're at home, they should only use the trusted password prompt. > > If that's the only justification/goal for the augmented PAKE (and your > replies suggest it is), let's just save the trouble and say "meh". > Please read the other half of my original email and most of my replies. I think that, even when using a second factor device (e.g. Fido, which you brought up), using an augmented PAKE style challenge for the device could improve security. This has no UX issue at all -- the whole technology is new, and the UI workflow suggested in the draft specs seems like it would work just fine with an improved challenge-response protocol. --Andy From nobody Thu Mar 20 01:52:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7651A06E8 for ; Thu, 20 Mar 2014 01:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pryi7LGiCaX for ; Thu, 20 Mar 2014 01:52:09 -0700 (PDT) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D6C301A068A for ; Thu, 20 Mar 2014 01:52:08 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id b15so372778eek.6 for ; Thu, 20 Mar 2014 01:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=++xEkeq5f2SowuxVLFAOy9g6DTpsbg/wCSfrYMnreoY=; b=LrlAkix9Ilh8KkjsyOR2nLEPymorUqU6kuBbrtEYdJEmeu9QiOH07TXio1C1v5BqSV nkQm2a6dnsBICyUCHIiuymJu369Oihizs7BPs+dYFjxxfOOVPMLB48A19NR82irWvl8R e61Kn4Gveeh5IaykgYU04lAly27ypbVvjDyGQZpLSS7DpTb/vyFaFAM3IXBjqtBPq4k+ mjMkGQJQbtPqav2/Uh1sk6Nts2T9lKJtG4ISJrnEkhCN8I8CfIqE39frKBHJpxoDaP22 UJ5XxxLbGHumMtTWsxqSIY8raH0XM/xd91esDKPQQSI+Q6qKE7rO1kScr9HR6cDNwNLF VXSA== X-Received: by 10.15.64.75 with SMTP id n51mr32272251eex.33.1395305519340; Thu, 20 Mar 2014 01:51:59 -0700 (PDT) Received: from [172.24.251.171] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id 4sm2748317eeq.33.2014.03.20.01.51.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Mar 2014 01:51:58 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3581B16D-DB2B-4899-9C85-485276905D2B" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: Date: Thu, 20 Mar 2014 10:51:55 +0200 Message-Id: <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> To: Andy Lutomirski X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yExjt9XfDtH9qMjsALX_JGahowU Cc: "tls@ietf.org" Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2014 08:52:12 -0000 --Apple-Mail=_3581B16D-DB2B-4899-9C85-485276905D2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Andy On Mar 19, 2014, at 6:45 PM, Andy Lutomirski = wrote: >=20 >>=20 >> My point is you can see on this list archives two common threads: >> - A desire to reduce, as much as possible, the complexity of TLS >> - Not a lot of fondness for another PAKE >>=20 >=20 > The only reason I think my suggestion is reasonable is that I think > that it could be very simple -- the main TLS key exchange be designed > to have all of the necessary cryptographic properties to be an > augmented PAKE. People who don't want to use it can specify null > passwords. I=92m sure you can add a PAKE to TLS, and it=92s already been done. = There=92s SRP. The fact that (as you said) it is hardly used suggests = that there is not much demand for it. I would argue that at least for the web (it may be different for IMAP) = the TLS layer is a really bad place to do the password exchange. The = application designers at https://www.example-bank.com, even assuming = that they are OK with getting a browser UI for authentication, don=92t = want to get that on the landing page. That page should have grand marble = structures and loan offers and most important, information that is = available to non-customers. You only want to pop up the browser UI after = the user clicks a =93Log in to my account=94 button. That is hard to do = in the authentication is in the TLS handshake. See a discussion about = client certificates on this and the http-bis list just a couple of weeks = ago. Of course, the assumption above is bogus, because as Ryan said, = application designers don=92t want to use the browser UI. There is some = work being done to make authentication at the HTTP layer more appealing = to them (see https://www.rcis.aist.go.jp/special/MutualAuth/ There=92s = even a modified Firefox and a test server ), but I don=92t have high = hopes for this succeeding. BTW: that work is done in conjunction with a = PAKE proposal for HTTP, which is not what the designers want, but it a = more appropriate layer than the transport layer. Over at http-auth we = are working on standardizing that http-layer PAKE, but I don=92t think = it will get much use. >> Note that the solution equally fails to meet your goals, because you = will >> always have browsers that don't support your solution - so sites = wanting >> to use it will still have to support 'naked' passwords. Equally, for >> browsers, there will always be sites that continue to support the = > type=3D"password"> authentication (not the least because it's part of >> HTML5), so they will always be phishable via downgrade attacks - not = of >> the TLS type, but of the UX type. >=20 > Right. And the better websites (banks?) will offer both and users > will learn that, when they're at home, they should only use the > trusted password prompt. Never say never, but so far getting users to avoid doing what they = intended to do just because there is some weirdness has not been = successful. When faced with a different UX, people will assume that the = bank has made a UX revision rather than that they are being attacked. = Most of the time, they would be right. If people walked away in the face = of a severe UX change, Facebook would have died five times by now. > Please read the other half of my original email and most of my > replies. I think that, even when using a second factor device (e.g. > Fido, which you brought up), using an augmented PAKE style challenge > for the device could improve security. This has no UX issue at all -- > the whole technology is new, and the UI workflow suggested in the > draft specs seems like it would work just fine with an improved > challenge-response protocol. The thing is, as long as the authentication happens in the application = layer, none of the fancy crypto matters. If my bank implements a PAKE in = the login screen using Javascript, a decent web designer can make a = website that looks identical, only the passwords go in the clear to the = phisher, and there is no fancy PAKE javascript. Good crypto in = indistinguishable from bad crypto or no crypto at all. Yoav --Apple-Mail=_3581B16D-DB2B-4899-9C85-485276905D2B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi, = Andy

On Mar 19, 2014, at 6:45 PM, Andy Lutomirski = <luto@amacapital.net> = wrote:



My= point is you can see on this list archives two common threads:
- A = desire to reduce, as much as possible, the complexity of TLS
- Not a = lot of fondness for another PAKE


The only reason = I think my suggestion is reasonable is that I think
that it could be = very simple -- the main TLS key exchange be designed
to have all of = the necessary cryptographic properties to be an
augmented PAKE. =  People who don't want to use it can specify = null
passwords.

I=92m sure you = can add a PAKE to TLS, and it=92s already been done. There=92s SRP. =  The fact that (as you said) it is hardly used suggests that there = is not much demand for it.

I would argue that = at least for the web (it may be different for IMAP) the TLS layer is a = really bad place to do the password exchange. The application designers = at https://www.example-bank.com, = even assuming that they are OK with getting a browser UI for = authentication, don=92t want to get that on the landing page. That page = should have grand marble structures and loan offers and most important, = information that is available to non-customers. You only want to pop up = the browser UI after the user clicks a =93Log in to my account=94 = button.  That is hard to do in the authentication is in the TLS = handshake. See a discussion about client certificates on this and the = http-bis list just a couple of weeks ago.

Of = course, the assumption above is bogus, because as Ryan said, application = designers don=92t want to use the browser UI. There is some work being = done to make authentication at the HTTP layer more appealing to them = (see https://www.rcis.= aist.go.jp/special/MutualAuth/  There=92s even a modified = Firefox and a test server ), but I don=92t have high hopes for this = succeeding. BTW: that work is done in conjunction with a PAKE proposal = for HTTP, which is not what the designers want, but it a more = appropriate layer than the transport layer. Over at http-auth we are = working on standardizing that http-layer PAKE, but I don=92t think it = will get much use.


Note = that the solution equally fails to meet your goals, because you = will
always have browsers that don't support your solution - so sites = wanting
to use it will still have to support 'naked' passwords. = Equally, for
browsers, there will always be sites that continue to = support the <input
type=3D"password"> authentication (not the = least because it's part of
HTML5), so they will always be phishable = via downgrade attacks - not of
the TLS type, but of the UX = type.

Right.  And the better websites (banks?) = will offer both and users
will learn that, when they're at home, they = should only use the
trusted password = prompt.

Never say never, but so far = getting users to avoid doing what they intended to do just because there = is some weirdness has not been successful. When faced with a different = UX, people will assume that the bank has made a UX revision rather than = that they are being attacked. Most of the time, they would be right. If = people walked away in the face of a severe UX change, Facebook would = have died five times by now.

Please read the other half of my = original email and most of my
replies.  I think that, even when = using a second factor device (e.g.
Fido, which you brought up), using = an augmented PAKE style challenge
for the device could improve = security.  This has no UX issue at all --
the whole technology = is new, and the UI workflow suggested in the
draft specs seems like = it would work just fine with an improved
challenge-response = protocol.

The thing is, as = long as the authentication happens in the application layer, none of the = fancy crypto matters. If my bank implements a PAKE in the login screen = using Javascript, a decent web designer can make a website that looks = identical, only the passwords go in the clear to the phisher, and there = is no fancy PAKE javascript. Good crypto in indistinguishable from bad = crypto or no crypto at = all.

Yoav


= --Apple-Mail=_3581B16D-DB2B-4899-9C85-485276905D2B-- From nobody Thu Mar 20 08:52:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70671A0763 for ; Thu, 20 Mar 2014 08:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4qw_STFPrd7 for ; Thu, 20 Mar 2014 08:52:20 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 69EF31A0743 for ; Thu, 20 Mar 2014 08:52:20 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A6568F984; Thu, 20 Mar 2014 11:52:09 -0400 (EDT) Message-ID: <532B0EAA.5040104@fifthhorseman.net> Date: Thu, 20 Mar 2014 11:52:10 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: Yoav Nir , Andy Lutomirski References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> In-Reply-To: <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rkOVObKunRVKAn8eIEApIcmgmrDrrhd3B" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OFt8uke1z4gZfNqi7qw_fnhRkxo Cc: "tls@ietf.org" Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2014 15:52:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rkOVObKunRVKAn8eIEApIcmgmrDrrhd3B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/20/2014 04:51 AM, Yoav Nir wrote: > The thing is, as long as the authentication happens in the application = layer, none of the fancy crypto matters. If my bank implements a PAKE in = the login screen using Javascript, a decent web designer can make a websi= te that looks identical, only the passwords go in the clear to the phishe= r, and there is no fancy PAKE javascript. Good crypto in indistinguishabl= e from bad crypto or no crypto at all. This is the core of the issue for client authentication in a web browser, i think. Regardless of whether we're talking about PAKE or client certs or some other mechanism, we have two choices: Either: A) We begin to establish a new norm for client-authentication UX that relies on unspoofable and easily-recognizable browser chrome (with some sort of browser-chrome logout mechanism as well), and start training users to distrust (perhaps at first on a site-by-site basis), taking some serious UX control away from web site designers. or: B) We continue to let web sites drive the full UX decisions, and leave users vulnerable to phishing attacks. option (A) is seriously hard, maybe impossible given the state of the web. option (B) is terrible. TLS can help this effort by making clear recommendations for how cryptographically strong authentication can be used, and tailoring some of those specifications for browsers that might want to use them. Already, we have discussions in httpbis about some additional HTTP mechanism so that the browser can trigger cryptographic use for client authentication in the TLS layer, and a proposed client-cert extension to make use of them: https://tools.ietf.org/html/draft-thomson-tls-care https://tools.ietf.org/html/draft-thomson-httpbis-catch This should provide a way for web sites to have full control over their unauthenticated UI and have well-specified mechanism that browser chrome can use when presenting client-authentication activity to the user. But Thomson's proposed scheme targets the use of client-side certs, not PAKE. If you really want PAKE to work as well in the HTTP context, it seems likely to have to think through the same cases. Perhaps the drafts above need to be modified to provide for SRP or some other PAKE as well as client-certs so that the same communications-flow can be used in a PAKE context at the TLS layer? If so, why would that be a better outcome than using PAKE directly at the HTTP layer (e.g. https://tools.ietf.org/html/draft-ietf-httpauth-mutual) ? --dkg --rkOVObKunRVKAn8eIEApIcmgmrDrrhd3B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTKw6qXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcznUQAIroLt0bvEiyT1skxvliwIwj sXppqm/VWclIvxDlxqnlHE0PP5z9zanW26milMwiWMxRWxczKVPBGg/wpICQUSCh vZ6fDI7u94Do2zqOw2h9Q+5+g3ao2H5OTYGVZLBuWtlIyi74c9T/0GKcrNXP8Ii4 WfwrzS2AH266l7h1NKspWfPDz3fAhs/OokNqSldAkJum/QDhfXsDak7lBBhZcBRz fw3q4KinIzE8qkJNpBz2RnLBEUFyjgCQtrhoGSKU8Se9UQDbMNZ33iSQVCNlFvK5 haR+H0zyiJk2Wl8gF9uB6VRmJ7sa+17sEhIkhfyjF4IGsWk+AZ7hSlY6JmmNG4df MqYbVr4V0svlFlGqhgqrfh3Vawy1WrIKS2+lBfbUzPaGpEheGZyIkAh0c3eks0NL vXmBlq5iWueHc40SP5d3AzjL051o4IEsu/zNGKh0Qx2KJ+zrJtfJ36VizUJnIU+a DmzdcI/nHEkDgd3Kndq5d/SO7tjKPC0mY2jXhlpfhn8zMIEfVd7QRZqhzU7EeK/O OfLTFZp5F2MQiD4z0SwoAUB0yOB//+V7cZ2VTchTKWxqwK4x019k844nmUGWU3pR hYZFzG0ADQaqxJERRLp9PAoPhUfIHAITOp7ZL/51DrctkB2z2/9hkGNzLbHJM+kY pmsxAxZPTxXAfHjXgbZ8 =K0rO -----END PGP SIGNATURE----- --rkOVObKunRVKAn8eIEApIcmgmrDrrhd3B-- From nobody Thu Mar 20 09:18:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D9C1A0457 for ; Thu, 20 Mar 2014 09:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5r4oA3WFdkD for ; Thu, 20 Mar 2014 09:18:43 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A5A711A048D for ; Thu, 20 Mar 2014 09:18:43 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2KGIXj1075199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Mar 2014 09:18:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <532B0EAA.5040104@fifthhorseman.net> Date: Thu, 20 Mar 2014 09:18:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> To: "tls@ietf.org" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lbvZ8CdN14tY_jNtq8t2eSoTOQ0 Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2014 16:18:44 -0000 On Mar 20, 2014, at 8:52 AM, Daniel Kahn Gillmor = wrote: > This is the core of the issue for client authentication in a web > browser, i think. Regardless of whether we're talking about PAKE or > client certs or some other mechanism, we have two choices: >=20 > Either: >=20 > A) We begin to establish a new norm for client-authentication UX that > relies on unspoofable and easily-recognizable browser chrome (with = some > sort of browser-chrome logout mechanism as well), and start training > users to distrust (perhaps at first on a > site-by-site basis), taking some serious UX control away from web site > designers. >=20 > or: >=20 > B) We continue to let web sites drive the full UX decisions, and leave > users vulnerable to phishing attacks. As an important note, you did not define "we" above. A few possible = expansions would be: - The TLS WG, where this thread currently lives, does not get to define = Web UI without a charter change. - The HTTPbis WG has not asked the TLS WG to take over this work, nor = has it embraced anything like it. - The IETF doesn't do this kind of work as a whole body. - The IAB (of which none of us are part of the "we") might take the = topic on and suggest ways which the IETF might do the work. > option (A) is seriously hard, maybe impossible given the state of the > web. option (B) is terrible. Exactly right, for any value of "we". --Paul Hoffman= From nobody Thu Mar 20 09:25:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D2A1A0906 for ; Thu, 20 Mar 2014 09:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5x-Yv1xPu1W for ; Thu, 20 Mar 2014 09:25:34 -0700 (PDT) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3466C1A08D0 for ; Thu, 20 Mar 2014 09:25:11 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id b57so859866eek.35 for ; Thu, 20 Mar 2014 09:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X9kIPokPwj7THbu7u6zgQrRlwFO5C9dTd7kTCdRJpFs=; b=gccmHN8kYzfrWnN7yQmFLDTQyxWo+CZATohCu5hGmQ/Qp7khf1uF4Igi+4BpwNe4iD DU+iR44vzyYYf4eRmByHfyqCxXUuCKSiy0FWTudNcmGbJRxMBOxgb89wQSwNeCVJc2qL HOLxai38gPNgZjDCOssks9IS2FHt8xynu2UhIc6kRnLQ9lb0LD9VVEBqONym+ANnyBIG N72C5PxNx5ibcw3L8CVTTuF6PxpceHEZy4cCloLgIrVteFUo57rUwEeC9mZ2bm2hqqzW Ts8vUmTtRllS9tPrA6Q4dQtqysE4YqlqKmmZ7xmCKBNvLXgu1gM8nMqvsY9j6sTtMa+E lBwQ== X-Received: by 10.15.76.9 with SMTP id m9mr6722069eey.96.1395332701767; Thu, 20 Mar 2014 09:25:01 -0700 (PDT) Received: from [172.24.251.171] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id 43sm5156208eeh.13.2014.03.20.09.25.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Mar 2014 09:25:00 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> Date: Thu, 20 Mar 2014 18:24:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cKr2bvVstwUt0usMy8RhCudEbHs Cc: "tls@ietf.org" Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2014 16:25:37 -0000 On Mar 20, 2014, at 6:18 PM, Paul Hoffman wrote: > On Mar 20, 2014, at 8:52 AM, Daniel Kahn Gillmor = wrote: >> This is the core of the issue for client authentication in a web >> browser, i think. Regardless of whether we're talking about PAKE or >> client certs or some other mechanism, we have two choices: >>=20 >> Either: >>=20 >> A) We begin to establish a new norm for client-authentication UX that >> relies on unspoofable and easily-recognizable browser chrome (with = some >> sort of browser-chrome logout mechanism as well), and start training >> users to distrust (perhaps at first on a >> site-by-site basis), taking some serious UX control away from web = site >> designers. >>=20 >> or: >>=20 >> B) We continue to let web sites drive the full UX decisions, and = leave >> users vulnerable to phishing attacks. >=20 > As an important note, you did not define "we" above. A few possible = expansions would be: Huh. I was about to reply =93you, me, Andy, and what army?=94 Seriously, we can=92t establish a new norm in any forum that does not = include web designers and UX people. Somewhere there are people who = design the UX for people browsing Facebook, Gmail, my bank, Amazon and = some web store selling dog food over the Internet. They get to decide = what technology goes into the web site, and unfortunately none of them = attend the meetings of any of the groups you mentioned. In fact, they = don=92t follow any IETF group, so we can=92t even invite them all to a = BoF. Given that, I don=92t think any value of =93we=94 that belongs to the = IETF can establish any norms. I wish this was different. Yoav From nobody Thu Mar 20 09:28:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5051A0785 for ; Thu, 20 Mar 2014 09:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlPfcJawBvpK for ; Thu, 20 Mar 2014 09:28:54 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB581A0782 for ; Thu, 20 Mar 2014 09:28:54 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id D34B5F984; Thu, 20 Mar 2014 12:28:43 -0400 (EDT) Message-ID: <532B1739.80907@fifthhorseman.net> Date: Thu, 20 Mar 2014 12:28:41 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: Paul Hoffman , "tls@ietf.org" References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> In-Reply-To: <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wuTkME10o79uGbIslhoHN4Voc6RPgpr0h" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xip9RpUNd6MtxoZcx5SHXznu6Qw Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2014 16:28:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wuTkME10o79uGbIslhoHN4Voc6RPgpr0h Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/20/2014 12:18 PM, Paul Hoffman wrote: > As an important note, you did not define "we" above. A few possible exp= ansions would be: >=20 > - The TLS WG, where this thread currently lives, does not get to define= Web UI without a charter change. >=20 > - The HTTPbis WG has not asked the TLS WG to take over this work, nor h= as it embraced anything like it. >=20 > - The IETF doesn't do this kind of work as a whole body. >=20 > - The IAB (of which none of us are part of the "we") might take the top= ic on and suggest ways which the IETF might do the work. yep, thanks for the clarification. I actually meant "we" in the broad sense of "the community of people who care about making communications on the web more secure", which includes groups you didn't even mention above, like web site designers, systems administrators, etc. It's still on-topic here (despite the broad scope implied above) because the TLS WG does have a role to play, by considering the merits of proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as well as considering alternatives that deal with this particular use case.= >> option (A) is seriously hard, maybe impossible given the state of the >> web. option (B) is terrible. >=20 > Exactly right, for any value of "we". :( --dkg --wuTkME10o79uGbIslhoHN4Voc6RPgpr0h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTKxc5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc2cAP/jrK/IqbttaGxGNQRl6hqQYG u9VShTaZnM2LO5/JIDc35JiVUUbyxUI7BoxZtseOskvJWjKjmTT6RNA65fyTF64p KS94WDJ6Qpzm0GNy01/uhHkIw/GqR+V4JFmBKn9zlgWWltbO6Wjf4a9FfRqMkAcr d5l7SxcK12G1pzMkr7PbM/V1HYsDsbp3tu5a851H6jI2xSGqwnRMeBbCtzrWewd1 MzjmI16y6vlSerlmFD6cjC0BqzQ7G2Z5IqVC2qFaeC9wbeDHBEHlz9/Qdj/ZMJtD M+IP/IzEWLtbRpgZ0rVe6fzvS9Ql/5MpvmTfDRCgAmMOidReCJvHg0pFAmj9Qz+h MPyxlskxQX1uM6/QWQJNMkuNzsUGGyiRZIein+fC7yfR0Va1dzCB1YvX6Qwg9q3b 7uHewlU3BecpY03PrFu8OUVzz+gaGN6N9Rxq4Pk49fE6bei+VgkNJPc5vjH/fic2 /8OLqun9PQNSjZ56oNu9NoUZL3SGAnaIbpNbvEZC9TCWALQcVhimREbREVXLAKTL s7HjE8a7uhvyB2oCvlrgtYKPVrNFIAft2gWcV0dmGejdNAUIliIvSMzi199sCafm mtRfgRhVAZQMvmgT2xQ3cfkyu2GS+dQUjsa21Sdg2CnTcxXIpTKYMYp/1FSVbB6a 8GN4s/LboTCvZnMHKHtJ =Iesl -----END PGP SIGNATURE----- --wuTkME10o79uGbIslhoHN4Voc6RPgpr0h-- From nobody Thu Mar 20 10:21:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5638E1A07C6 for ; Thu, 20 Mar 2014 10:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1-cEG03DKqQ for ; Thu, 20 Mar 2014 10:21:34 -0700 (PDT) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6B84B1A0700 for ; Thu, 20 Mar 2014 10:21:34 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id t10so916461eei.19 for ; Thu, 20 Mar 2014 10:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=26r3vt2AUou+sv/o00Tp+IBHSENcp7imZti7R3ewe30=; b=IAhP/g71MNf4s459wwZ/p+nlTsUj8Iar27/jUG3fYW7LE0IY9oItjayWrUviPUwZLh sxnDurxFBr1HMIKqdiVo8091gJw/HYhS3dtbUNkzrpi3+G+1gfEUnMFCGXnvTAOq3MKs Tf0WWNFzVc5YsMXXniAUt/thhgw9PcxAqXL3cRigvppPFzY0B5o8XDkPLc1iOIFdoKP2 K5+TMusFPnx7EPySyDH59G+iK0hu8I3il9LfunY+VotaBhv3wviKzZQIIpU6Dw8pbzb/ 3Cmto4G05EXFaduWcC9IlVk9Hcf3WsK+U6ELqY2NMDlhAt50sSfstqex7RqrnRtC9CuK G7YQ== MIME-Version: 1.0 X-Received: by 10.15.33.129 with SMTP id c1mr10577269eev.85.1395336084937; Thu, 20 Mar 2014 10:21:24 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.14.116.131 with HTTP; Thu, 20 Mar 2014 10:21:24 -0700 (PDT) Received: by 10.14.116.131 with HTTP; Thu, 20 Mar 2014 10:21:24 -0700 (PDT) In-Reply-To: <532B1739.80907@fifthhorseman.net> References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> Date: Thu, 20 Mar 2014 17:21:24 +0000 X-Google-Sender-Auth: oTBvoFJlrCxXrEPmvIB-8Bm1a-g Message-ID: From: Robert Cragie To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=089e01681ea6af613a04f50cffe8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cW4Oq7x0PlpMswf19vVNTEJT_WY Cc: tls@ietf.org, Paul Hoffman Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.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, 20 Mar 2014 17:21:36 -0000 --089e01681ea6af613a04f50cffe8 Content-Type: text/plain; charset=ISO-8859-1 It should be remembered that TLS is used in places other than web browsers - the existence of the DICE WG is testament to this. There is a lot of interest in the IoT community in using some form of PAKE in conjunction with DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT devices onto IoT networks. I realise this is different to the original proposition in this thread but wanted to draw this to the attention of the WG nevertheless. Robert On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" wrote: > On 03/20/2014 12:18 PM, Paul Hoffman wrote: > > As an important note, you did not define "we" above. A few possible > expansions would be: > > > > - The TLS WG, where this thread currently lives, does not get to define > Web UI without a charter change. > > > > - The HTTPbis WG has not asked the TLS WG to take over this work, nor > has it embraced anything like it. > > > > - The IETF doesn't do this kind of work as a whole body. > > > > - The IAB (of which none of us are part of the "we") might take the > topic on and suggest ways which the IETF might do the work. > > yep, thanks for the clarification. I actually meant "we" in the broad > sense of "the community of people who care about making communications > on the web more secure", which includes groups you didn't even mention > above, like web site designers, systems administrators, etc. > > It's still on-topic here (despite the broad scope implied above) because > the TLS WG does have a role to play, by considering the merits of > proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as > well as considering alternatives that deal with this particular use case. > > >> option (A) is seriously hard, maybe impossible given the state of the > >> web. option (B) is terrible. > > > > Exactly right, for any value of "we". > > :( > > --dkg > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e01681ea6af613a04f50cffe8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

It should be remembered that TLS is used in places other tha= n web browsers - the existence of the DICE WG is testament to this. There i= s a lot of interest in the IoT community in using some form of PAKE in conj= unction with DTLS (or TLS with EAP) for authenticating commissioning/bootst= rapping of IoT devices onto IoT networks. I realise this is different to th= e original proposition in this thread but wanted to draw this to the attent= ion of the WG nevertheless.

Robert

On 20 Mar 2014 12:28, "Daniel Kahn Gillmor&= quot; <dkg@fifthhorseman.net> wrote:
On 03/20/2014 12:18 PM, Paul Hoffman wrote:
> As an important note, you did not define "we" above. A few p= ossible expansions would be:
>
> - The TLS WG, where this thread currently lives, does not get to defin= e Web UI without a charter change.
>
> - The HTTPbis WG has not asked the TLS WG to take over this work, nor = has it embraced anything like it.
>
> - The IETF doesn't do this kind of work as a whole body.
>
> - The IAB (of which none of us are part of the "we") might t= ake the topic on and suggest ways which the IETF might do the work.

yep, thanks for the clarification. =A0I actually meant "we" in th= e broad
sense of "the community of people who care about making communications=
on the web more secure", which includes groups you didn't even men= tion
above, like web site designers, systems administrators, etc.

It's still on-topic here (despite the broad scope implied above) becaus= e
the TLS WG does have a role to play, by considering the merits of
proposals like http://tools.ietf.org/html/draft-thomson-tls-care, = as
well as considering alternatives that deal with this particular use case.
>> option (A) is seriously hard, maybe impossible given the state of = the
>> web. =A0option (B) is terrible.
>
> Exactly right, for any value of "we".

:(

=A0 =A0 =A0 =A0 --dkg


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

--089e01681ea6af613a04f50cffe8-- From nobody Thu Mar 20 18:52:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F361A0601 for ; Thu, 20 Mar 2014 18:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ii51C1TzG7Pg for ; Thu, 20 Mar 2014 18:52:53 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2208B1A04B8 for ; Thu, 20 Mar 2014 18:52:53 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id jt11so1773428pbb.0 for ; Thu, 20 Mar 2014 18:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=CObb+HvXNPJLATyqta5we/UOSPUV+GRfPSJOlP06/2g=; b=goEiTqxbFrTtW952BHaCgQvWUv+8CV/PO1rCzYuOUtrjqaDIZ8zOD3KAVBavqk2mBu t71UYIauB39momDOlOM/xAKtOW76Tlo0UgjkhcyTXmmGJZ9jcJ36utYm4FmTcytTGVYS Q/Br1zFEvSxq+EP1os1bVnx8a+xCcFiXUsiRBY/UrWyGMwmLlMnNhLYQBNDbVbN9/QaY 8iBzMNcLlyOBOzmwEjAYOfsh1U0Fb6CKJVUYfn0FthN9C6v5cqsjP3opVX+dJ4WSlbhN 43xNSl1I5Fzzg4LuZyUcNJ2IaUNodYOtrpwSo6y+8OJq9WiOI8Ap4bjVrocVxPWO8TsC oOPw== X-Received: by 10.66.149.7 with SMTP id tw7mr51167950pab.72.1395366764034; Thu, 20 Mar 2014 18:52:44 -0700 (PDT) Received: from ?IPv6:2001:470:f38b:16:f408:96cc:5bcd:388? ([2001:470:f38b:16:f408:96cc:5bcd:388]) by mx.google.com with ESMTPSA id n6sm6550994pbj.22.2014.03.20.18.52.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Mar 2014 18:52:42 -0700 (PDT) Message-ID: <532B9B65.4030708@gmail.com> Date: Thu, 20 Mar 2014 21:52:37 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: robert.cragie@gridmerge.com, "'tls@ietf.org'" References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020608020402090402030008" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RazcX6YjnZbE0lvtEL_rjD5RYiM Subject: [TLS] bootstrapping of constrained devices (was: Re: Should TLS 1.3 use an augmented PAKE by default?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2014 01:52:55 -0000 This is a multi-part message in MIME format. --------------020608020402090402030008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Robert: Wouldn't it be much easier to embed device certificates with constrained devices at manufacturing? This may do away with need to store info that is not public on servers. If you could provide some links to discussions in "IoT community groups" interested in this, that would help. Best regards, Rene == There is a lot of interest in the IoT community in using some form of PAKE in conjunction with DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT devices onto IoT networks On 3/20/2014 1:21 PM, Robert Cragie wrote: > > It should be remembered that TLS is used in places other than web > browsers - the existence of the DICE WG is testament to this. There is > a lot of interest in the IoT community in using some form of PAKE in > conjunction with DTLS (or TLS with EAP) for authenticating > commissioning/bootstrapping of IoT devices onto IoT networks. I > realise this is different to the original proposition in this thread > but wanted to draw this to the attention of the WG nevertheless. > > Robert > > On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" > wrote: > > On 03/20/2014 12:18 PM, Paul Hoffman wrote: > > As an important note, you did not define "we" above. A few > possible expansions would be: > > > > - The TLS WG, where this thread currently lives, does not get to > define Web UI without a charter change. > > > > - The HTTPbis WG has not asked the TLS WG to take over this > work, nor has it embraced anything like it. > > > > - The IETF doesn't do this kind of work as a whole body. > > > > - The IAB (of which none of us are part of the "we") might take > the topic on and suggest ways which the IETF might do the work. > > yep, thanks for the clarification. I actually meant "we" in the broad > sense of "the community of people who care about making communications > on the web more secure", which includes groups you didn't even mention > above, like web site designers, systems administrators, etc. > > It's still on-topic here (despite the broad scope implied above) > because > the TLS WG does have a role to play, by considering the merits of > proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as > well as considering alternatives that deal with this particular > use case. > > >> option (A) is seriously hard, maybe impossible given the state > of the > >> web. option (B) is terrible. > > > > Exactly right, for any value of "we". > > :( > > --dkg > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------020608020402090402030008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Robert:

Wouldn't it be much easier to embed device certificates with constrained devices at manufacturing? This may do away with need to store info that is not public on servers.

If you could provide some links to discussions in "IoT community groups" interested in this, that would help.

Best regards, Rene

==
There is a lot of interest in the IoT community in using some form of PAKE in conjunction with DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT devices onto IoT networks

On 3/20/2014 1:21 PM, Robert Cragie wrote:

It should be remembered that TLS is used in places other than web browsers - the existence of the DICE WG is testament to this. There is a lot of interest in the IoT community in using some form of PAKE in conjunction with DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT devices onto IoT networks. I realise this is different to the original proposition in this thread but wanted to draw this to the attention of the WG nevertheless.

Robert

On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net> wrote:
On 03/20/2014 12:18 PM, Paul Hoffman wrote:
> As an important note, you did not define "we" above. A few possible expansions would be:
>
> - The TLS WG, where this thread currently lives, does not get to define Web UI without a charter change.
>
> - The HTTPbis WG has not asked the TLS WG to take over this work, nor has it embraced anything like it.
>
> - The IETF doesn't do this kind of work as a whole body.
>
> - The IAB (of which none of us are part of the "we") might take the topic on and suggest ways which the IETF might do the work.

yep, thanks for the clarification.  I actually meant "we" in the broad
sense of "the community of people who care about making communications
on the web more secure", which includes groups you didn't even mention
above, like web site designers, systems administrators, etc.

It's still on-topic here (despite the broad scope implied above) because
the TLS WG does have a role to play, by considering the merits of
proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as
well as considering alternatives that deal with this particular use case.

>> option (A) is seriously hard, maybe impossible given the state of the
>> web.  option (B) is terrible.
>
> Exactly right, for any value of "we".

:(

        --dkg


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



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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------020608020402090402030008-- From nobody Thu Mar 20 20:56:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F211A0919 for ; Thu, 20 Mar 2014 20:56:10 -0700 (PDT) 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 XrXXYvOpo4xx for ; Thu, 20 Mar 2014 20:56:08 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 835121A0918 for ; Thu, 20 Mar 2014 20:56:08 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hm4so174974wib.2 for ; Thu, 20 Mar 2014 20:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=hESjoREWXKH6fQzetp6M3lsCdCzJqmlaH2UrpTpWHEg=; b=E1VAuw3NDnJIHp/hwcHL9Sr12jcicoSJTujhcsSP7zt6hlKKi9/CkQR02dzlFCpWRy StMgJD+YSnVoq6A4dJKxrRsD/wXQVkXsbi6wUFv7eAmJw5CyGALHbWqUsXbDuOJtoJQP LY/R3SJQ9n3KqwHl0BCQy/FuPlnd3Q4oAMqiHHNuRs94RDH0362fZIFJh44XytC+1jjH P1gnuccN2RPqRJ/UEKqqkEDSpMDaDpxVBtmXEJaOyO/FBRyQbLwR5uuP7CBZa1aYoUg2 aHj7sN6POR+LYWSBnv+V0yjS1z/qG+tbh107l0eOHV9c9l0NTEFdYiNnBd3LjOZIk8DD JH3Q== X-Received: by 10.180.98.165 with SMTP id ej5mr345581wib.33.1395374158794; Thu, 20 Mar 2014 20:55:58 -0700 (PDT) Received: from [192.168.1.99] (188.110.176.95.rev.sfr.net. [95.176.110.188]) by mx.google.com with ESMTPSA id fs4sm1128433wib.11.2014.03.20.20.55.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Mar 2014 20:55:58 -0700 (PDT) Message-ID: <532BB846.2030300@gmail.com> Date: Fri, 21 Mar 2014 04:55:50 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Rene Struik , robert.cragie@gridmerge.com, "'tls@ietf.org'" References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <532B9B65.4030708@gmail.com> In-Reply-To: <532B9B65.4030708@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/477x2ZnB3jNtrRq62xm9xBhkin8 Subject: Re: [TLS] bootstrapping of constrained devices X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2014 03:56:10 -0000 On 2014-03-21 02:52, Rene Struik wrote: > Hi Robert: > > Wouldn't it be much easier to embed device certificates with constrained devices at manufacturing? This may do away with need to store info that is not public on servers. +1 way to go > > If you could provide some links to discussions in "IoT community groups" interested in this, that would help. > > Best regards, Rene > > == > There is a lot of interest in the IoT community in using some form of PAKE in conjunction with DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT devices onto IoT networks > > On 3/20/2014 1:21 PM, Robert Cragie wrote: >> >> It should be remembered that TLS is used in places other than web browsers - the existence of the DICE WG is testament to this. There is a lot of interest in the IoT community in using some form of PAKE in conjunction with DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT devices onto IoT networks. I realise this is different to the original proposition in this thread but wanted to draw this to the attention of the WG nevertheless. >> >> Robert >> >> On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" > wrote: >> >> On 03/20/2014 12:18 PM, Paul Hoffman wrote: >> > As an important note, you did not define "we" above. A few possible expansions would be: >> > >> > - The TLS WG, where this thread currently lives, does not get to define Web UI without a charter change. >> > >> > - The HTTPbis WG has not asked the TLS WG to take over this work, nor has it embraced anything like it. >> > >> > - The IETF doesn't do this kind of work as a whole body. >> > >> > - The IAB (of which none of us are part of the "we") might take the topic on and suggest ways which the IETF might do the work. >> >> yep, thanks for the clarification. I actually meant "we" in the broad >> sense of "the community of people who care about making communications >> on the web more secure", which includes groups you didn't even mention >> above, like web site designers, systems administrators, etc. >> >> It's still on-topic here (despite the broad scope implied above) because >> the TLS WG does have a role to play, by considering the merits of >> proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as >> well as considering alternatives that deal with this particular use case. >> >> >> option (A) is seriously hard, maybe impossible given the state of the >> >> web. option (B) is terrible. >> > >> > Exactly right, for any value of "we". >> >> :( >> >> --dkg >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Mar 21 02:56:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A50D1A06FC for ; Fri, 21 Mar 2014 02:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, 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 vMcy_aW6MzQW for ; Fri, 21 Mar 2014 02:56:51 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0078.outbound.protection.outlook.com [213.199.154.78]) by ietfa.amsl.com (Postfix) with ESMTP id 563A01A0784 for ; Fri, 21 Mar 2014 02:56:50 -0700 (PDT) Received: from AMXPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.133) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.0.898.11; Fri, 21 Mar 2014 09:56:39 +0000 Message-ID: <004b01cf44eb$120ed900$4001a8c0@gateway.2wire.net> From: t.petch To: "Joseph Salowey (jsalowey)" , References: Date: Fri, 21 Mar 2014 09:50:46 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AMSPR07CA015.eurprd07.prod.outlook.com (10.242.225.173) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) X-Forefront-PRVS: 0157DEB61B X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(1?= =?iso-8859-1?Q?3464003)(377454003)(51704005)(51856001)(90146001)(56816005?= =?iso-8859-1?Q?)(14496001)(97186001)(33646001)(79102001)(89996001)(973360?= =?iso-8859-1?Q?01)(15202345003)(77096001)(83072002)(46102001)(59766001)(6?= =?iso-8859-1?Q?2236002)(53806001)(88136002)(42186004)(62966002)(44716002)?= =?iso-8859-1?Q?(77156001)(85852003)(66066001)(92566001)(81542001)(6581600?= =?iso-8859-1?Q?1)(74876001)(74706001)(50466002)(93136001)(80022001)(61296?= =?iso-8859-1?Q?002)(85306002)(87266001)(76796001)(20776003)(87286001)(477?= =?iso-8859-1?Q?76003)(92726001)(76786001)(63696002)(74366001)(87976001)(7?= =?iso-8859-1?Q?6482001)(50986001)(93516002)(69226001)(74502001)(47446002)?= =?iso-8859-1?Q?(93916002)(81342001)(83322001)(19580405001)(94946001)(1958?= =?iso-8859-1?Q?0395003)(23756003)(95666003)(44736004)(94316002)(95416001)?= =?iso-8859-1?Q?(74662001)(47976001)(49866001)(84392001)(47736001)(5677600?= =?iso-8859-1?Q?1)(54316002)(77982001)(86362001)(31966008)(15975445006)(43?= =?iso-8859-1?Q?96001)(50226001)(80976001)(74416001)(7726001);DIR:OUT;SFP:?= =?iso-8859-1?Q?1101;SCL:1;SRVR:AMXPR07MB056;H:AMXPRD0310HT004.eurprd03.pr?= =?iso-8859-1?Q?od.outlook.com;FPR:BE7D797A.ACE6ACF6.BD5ABFAF.4CA25BE0.201?= =?iso-8859-1?Q?5F;MLV:nov;PTR:InfoNoRecords;MX:1;A:0;LANG:en;?= Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/prJqRMeitUzsxVC6Faq3SCmHPGQ Subject: [TLS] Virtual Interim Re: Draft meeting minutes from IETF 89 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2014 09:56:54 -0000 One topic in the TLS minutes from IETF89 was the idea of having a virtual(?) interim meeting with the CFRG in early April. If so, I suspect that two weeks notice is required on this list (the last IESG statement does not cater for virtual interims, only face-to-face and conference calls) in which case time is slipping by - or may be already has. Tom Petch ----- Original Message ----- From: "Joseph Salowey (jsalowey)" To: Sent: Friday, March 14, 2014 4:07 PM > Draft meeting minutes from IETF 89 are available at: > > http://www.ietf.org/proceedings/89/minutes/minutes-89-tls > > Cheers, > > Joe > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Mar 21 05:26:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9471A0983 for ; Fri, 21 Mar 2014 05:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 Y_WuBM9M2lbk for ; Fri, 21 Mar 2014 05:26:14 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id D87871A0969 for ; Fri, 21 Mar 2014 05:26:14 -0700 (PDT) MIME-version: 1.0 Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N2S00B7FD7511T0@mail-out.apple.com> for tls@ietf.org; Fri, 21 Mar 2014 05:26:05 -0700 (PDT) X-AuditID: 11807157-f79aa6d0000017b2-39-532c2fdd975e Received: from orrisroot.apple.com (orrisroot.apple.com [17.128.115.106]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 50.3F.06066.DDF2C235; Fri, 21 Mar 2014 05:26:05 -0700 (PDT) Received: from [17.153.37.122] (unknown [17.153.37.122]) by orrisroot.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N2S00LULD7E1A40@orrisroot.apple.com> for tls@ietf.org; Fri, 21 Mar 2014 05:26:05 -0700 (PDT) Content-type: multipart/signed; boundary="Apple-Mail=_9B214BC4-DC20-4895-88DF-E456C23EC046"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <532B9B65.4030708@gmail.com> Date: Fri, 21 Mar 2014 08:26:02 -0400 Message-id: <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com> References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <532B9B65.4030708@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1874) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUi2FCcpXtXXyfY4PcbAYtP57sYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8fj/NPaCh5MYK9b/X8ncwPintouRk0NCwERi1o4GFghbTOLC vfVsILaQwBQmiUVfzSDsBUwSLWsYQWxhgVKJP6tus4LYvAJ6EmfO/mLvYuTiYBaYwijRsPw0 E0iCTUBN4vekPrAiTgFNiU3HFoEtYBFQleiafJsZxGYWsJN4/3EGO8QgG4kTV06wggwSEpjK KvG4+zFYkYiAusT83bPZIK6TlXj0oYllAiP/LCTLZyFbPgtscJLE7I+v2SFsbYllC18zQ9h6 Ei+b3mER15W4uG4SI4RtKvHk7XY2CNta4uecR1BxRYkp3Q/ZFzByrWIUKErNSaw00UssKMhJ 1UvOz93ECI6HwvAdjP+WWR1iFOBgVOLhreTUDhZiTSwrrsw9xKgCNOLRhtUXGKVY8vLzUpVE eOW0dIKFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8z41AuoUSE8sSc1OTS1ILYLJMnFwSjUwNm08 Uzz38o8CV1m9OTzXLn1oUq8su7ck/s+vC2f/zf9bUOz6du/Lq2br614u/mtWuVbQQ/0M/w6B PolLKfvcFHwFGa0+B07ZVNQ81XHbpqfhB5KcYmy9Jk9tSTt+9Lm+VKOtywYGlaXaem8dr/Gd fHFSL4rFeJ/I1q0Gf+UmGU8oY/VgZmm8pMRSnJFoqMVcVJwIALOHYZiPAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4sJgqhMD7YnbJBKppsOBeNWAxIg Cc: "tls@ietf.org" Subject: Re: [TLS] bootstrapping of constrained devices (was: Re: Should TLS 1.3 use an augmented PAKE by default?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2014 12:26:17 -0000 --Apple-Mail=_9B214BC4-DC20-4895-88DF-E456C23EC046 Content-Type: multipart/alternative; boundary="Apple-Mail=_1A79CAE9-70EC-4D67-90A7-EDFB0DE1A2AA" --Apple-Mail=_1A79CAE9-70EC-4D67-90A7-EDFB0DE1A2AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Rene, Installing device certificates during manufacturing is not a simple = process - the factory would need to act as a CA or would need to have a = supply of certificates that matches whatever identifiers are used by the = devices. Not to mention how you'd manage revocation if the root was = compromised... On Mar 20, 2014, at 9:52 PM, Rene Struik wrote: > Hi Robert: >=20 > Wouldn't it be much easier to embed device certificates with = constrained devices at manufacturing? This may do away with need = to store info that is not public on servers. >=20 > If you could provide some links to discussions in "IoT community = groups" interested in this, that would help. >=20 > Best regards, Rene >=20 > =3D=3D > There is a lot of interest in the IoT community in using some form of = PAKE in conjunction with DTLS (or TLS with EAP) for authenticating = commissioning/bootstrapping of IoT devices onto IoT networks >=20 > On 3/20/2014 1:21 PM, Robert Cragie wrote: >> It should be remembered that TLS is used in places other than web = browsers - the existence of the DICE WG is testament to this. There is a = lot of interest in the IoT community in using some form of PAKE in = conjunction with DTLS (or TLS with EAP) for authenticating = commissioning/bootstrapping of IoT devices onto IoT networks. I realise = this is different to the original proposition in this thread but wanted = to draw this to the attention of the WG nevertheless. >>=20 >> Robert >>=20 >> On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" = wrote: >> On 03/20/2014 12:18 PM, Paul Hoffman wrote: >> > As an important note, you did not define "we" above. A few possible = expansions would be: >> > >> > - The TLS WG, where this thread currently lives, does not get to = define Web UI without a charter change. >> > >> > - The HTTPbis WG has not asked the TLS WG to take over this work, = nor has it embraced anything like it. >> > >> > - The IETF doesn't do this kind of work as a whole body. >> > >> > - The IAB (of which none of us are part of the "we") might take the = topic on and suggest ways which the IETF might do the work. >>=20 >> yep, thanks for the clarification. I actually meant "we" in the = broad >> sense of "the community of people who care about making = communications >> on the web more secure", which includes groups you didn't even = mention >> above, like web site designers, systems administrators, etc. >>=20 >> It's still on-topic here (despite the broad scope implied above) = because >> the TLS WG does have a role to play, by considering the merits of >> proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as >> well as considering alternatives that deal with this particular use = case. >>=20 >> >> option (A) is seriously hard, maybe impossible given the state of = the >> >> web. option (B) is terrible. >> > >> > Exactly right, for any value of "we". >>=20 >> :( >>=20 >> --dkg >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > --=20 > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_1A79CAE9-70EC-4D67-90A7-EDFB0DE1A2AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Rene,

Installing device = certificates during manufacturing is not a simple process - the factory = would need to act as a CA or would need to have a supply of certificates = that matches whatever identifiers are used by the devices.  Not to = mention how you'd manage revocation if the root was = compromised...


On Mar = 20, 2014, at 9:52 PM, Rene Struik <rstruik.ext@gmail.com> = wrote:

=20 =20
Hi Robert:

Wouldn't it be much easier to embed device certificates with constrained devices at manufacturing? This may do away with need to store info that is not public on servers.

If you could provide some links to discussions in "IoT community groups" interested in this, that would help.

Best regards, Rene

=3D=3D
There is a lot of interest in the IoT community in using some form of PAKE in conjunction with DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT devices onto IoT networks

On 3/20/2014 1:21 PM, Robert Cragie wrote:

It should be remembered that TLS is = used in places other than web browsers - the existence of the DICE WG is testament to this. There is a lot of interest in the IoT community in using some form of PAKE in conjunction with DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT devices onto IoT networks. I realise this is different to the original proposition in this thread but wanted to draw this to the attention of the WG nevertheless.

Robert

On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net> wrote:
On 03/20/2014 12:18 PM, Paul Hoffman wrote:
> As an important note, you did not define "we" above. A few possible expansions would be:
>
> - The TLS WG, where this thread currently lives, does not get to define Web UI without a charter change.
>
> - The HTTPbis WG has not asked the TLS WG to take over this work, nor has it embraced anything like it.
>
> - The IETF doesn't do this kind of work as a whole = body.
>
> - The IAB (of which none of us are part of the "we") might take the topic on and suggest ways which the IETF might do the work.

yep, thanks for the clarification.  I actually meant "we" = in the broad
sense of "the community of people who care about making communications
on the web more secure", which includes groups you didn't even mention
above, like web site designers, systems administrators, = etc.

It's still on-topic here (despite the broad scope implied above) because
the TLS WG does have a role to play, by considering the merits of
proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as
well as considering alternatives that deal with this particular use case.

>> option (A) is seriously hard, maybe impossible given the state of the
>> web.  option (B) is terrible.
>
> Exactly right, for any value of "we".

:(

        --dkg


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



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/tls



--=20
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/mail= man/listinfo/tls

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Apple-Mail=_1A79CAE9-70EC-4D67-90A7-EDFB0DE1A2AA-- --Apple-Mail=_9B214BC4-DC20-4895-88DF-E456C23EC046 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMzIxMTIyNjAyWjAjBgkqhkiG9w0BCQQxFgQUXAiXLYwdtyOhF57Q2mtu+hkq /lcwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQCKB0xruPzDKixprvTtfH0dKVacQqEfRki24kimVGYke1Rn0LvZsXJ1P4pJG3X4hyW7kc0BWpl6 jSz2rEnaZ8Fr3MNCXDpbyquNAKPq3a1/DNIMPlZxTZhs19bcttTYajAlRQ4M8P4k5XAC2YQf20iw 2B+J4zUl67lmdtDZuXMOQh4eTtS45m3lFTJpGeIqsn/kuC4jI6vReqCewvUGPCHY0h2jZlKYvAY6 Nx5V18IGa02Vz0OtEZDmbvdyW9t5U8CNvIafDKXIGBqlkv4n9sqJ59QH+0u7DKW8KhdK+jTDhBPw eo71lqASWA4BmYqhCPt/4CggBRw9FWrdFkTC8t2nAAAAAAAA --Apple-Mail=_9B214BC4-DC20-4895-88DF-E456C23EC046-- From nobody Fri Mar 21 07:50:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F971A0993 for ; Fri, 21 Mar 2014 07:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 vdl-G4bAY2TG for ; Fri, 21 Mar 2014 07:50:37 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0076.outbound.protection.outlook.com [213.199.154.76]) by ietfa.amsl.com (Postfix) with ESMTP id B40541A0989 for ; Fri, 21 Mar 2014 07:50:36 -0700 (PDT) Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.898.11; Fri, 21 Mar 2014 14:50:25 +0000 Message-ID: <045401cf4514$1c0e5ec0$4001a8c0@gateway.2wire.net> From: t.petch To: Michael Sweet , Rene Struik References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <532B9B65.4030708@gmail.com> <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com> Date: Fri, 21 Mar 2014 14:44:41 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AM3PR07CA003.eurprd07.prod.outlook.com (10.242.16.43) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 0157DEB61B X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(2445400?= =?iso-8859-1?Q?2)(51914003)(13464003)(377454003)(189002)(199002)(47917400?= =?iso-8859-1?Q?3)(74366001)(50466002)(83072002)(85852003)(15202345003)(42?= =?iso-8859-1?Q?186004)(88136002)(4396001)(77982001)(56816005)(90146001)(1?= =?iso-8859-1?Q?9580395003)(83322001)(19580405001)(46102001)(63696002)(899?= =?iso-8859-1?Q?96001)(53806001)(44716002)(62236002)(50226001)(79102001)(4?= =?iso-8859-1?Q?7736001)(51856001)(44736004)(87976001)(33646001)(47776003)?= =?iso-8859-1?Q?(49866001)(59766001)(74706001)(20776003)(50986001)(6581600?= =?iso-8859-1?Q?1)(93136001)(76482001)(92566001)(80022001)(92726001)(87266?= =?iso-8859-1?Q?001)(23756003)(56776001)(93516002)(54316002)(77156001)(767?= =?iso-8859-1?Q?86001)(77096001)(97186001)(85306002)(325944007)(74876001)(?= =?iso-8859-1?Q?66066001)(87286001)(61296002)(94316002)(74662001)(80976001?= =?iso-8859-1?Q?)(561944002)(47976001)(69226001)(14496001)(76796001)(31966?= =?iso-8859-1?Q?008)(62966002)(93916002)(47446002)(86362001)(81342001)(745?= =?iso-8859-1?Q?02001)(81542001)(94946001)(95666003)(15975445006)(95416001?= =?iso-8859-1?Q?)(74416001)(7726001);DIR:OUT;SFP:1101;SCL:1;SRVR:DB3PR07MB?= =?iso-8859-1?Q?060;H:AMXPRD0310HT002.eurprd03.prod.outlook.com;FPR:F6D7F4?= =?iso-8859-1?Q?F4.9EF867E1.BDF45DBF.C2E5D979.204C5;MLV:sfv;PTR:InfoNoReco?= =?iso-8859-1?Q?rds;MX:1;A:0;LANG:en;?= Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4bvDzwHFDTdxcqK_468YjQed71s Cc: tls@ietf.org Subject: Re: [TLS] bootstrapping of constrained devices (was: Re: Should TLS 1.3 use an augmented PAKE by default?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2014 14:50:43 -0000 ----- Original Message ----- From: "Michael Sweet" To: "Rene Struik" Cc: Sent: Friday, March 21, 2014 12:26 PM Rene, Installing device certificates during manufacturing is not a simple process - the factory would need to act as a CA or would need to have a supply of certificates that matches whatever identifiers are used by the devices. Not to mention how you'd manage revocation if the root was compromised... Michael In the context of syslog security, some years ago now, the question of device certificates arose and it was said there that they were quite common. They would be self-signed, which gives much of the needed security, while avoiding issues of CA and root compromise. Tom Petch On Mar 20, 2014, at 9:52 PM, Rene Struik wrote: > Hi Robert: > > Wouldn't it be much easier to embed device certificates with constrained devices at manufacturing? This may do away with need to store info that is not public on servers. > > If you could provide some links to discussions in "IoT community groups" interested in this, that would help. > > Best regards, Rene > > == > There is a lot of interest in the IoT community in using some form of PAKE in conjunction with DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT devices onto IoT networks > > On 3/20/2014 1:21 PM, Robert Cragie wrote: >> It should be remembered that TLS is used in places other than web browsers - the existence of the DICE WG is testament to this. There is a lot of interest in the IoT community in using some form of PAKE in conjunction with DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT devices onto IoT networks. I realise this is different to the original proposition in this thread but wanted to draw this to the attention of the WG nevertheless. >> >> Robert >> >> On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" wrote: >> On 03/20/2014 12:18 PM, Paul Hoffman wrote: >> > As an important note, you did not define "we" above. A few possible expansions would be: >> > >> > - The TLS WG, where this thread currently lives, does not get to define Web UI without a charter change. >> > >> > - The HTTPbis WG has not asked the TLS WG to take over this work, nor has it embraced anything like it. >> > >> > - The IETF doesn't do this kind of work as a whole body. >> > >> > - The IAB (of which none of us are part of the "we") might take the topic on and suggest ways which the IETF might do the work. >> >> yep, thanks for the clarification. I actually meant "we" in the broad >> sense of "the community of people who care about making communications >> on the web more secure", which includes groups you didn't even mention >> above, like web site designers, systems administrators, etc. >> >> It's still on-topic here (despite the broad scope implied above) because >> the TLS WG does have a role to play, by considering the merits of >> proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as >> well as considering alternatives that deal with this particular use case. >> >> >> option (A) is seriously hard, maybe impossible given the state of the >> >> web. option (B) is terrible. >> > >> > Exactly right, for any value of "we". >> >> :( >> >> --dkg >> >> > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From nobody Fri Mar 21 07:58:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388651A09AF for ; Fri, 21 Mar 2014 07:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.149 X-Spam-Level: X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 IHTCmnQC-BLk for ; Fri, 21 Mar 2014 07:57:56 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE581A099C for ; Fri, 21 Mar 2014 07:57:56 -0700 (PDT) MIME-version: 1.0 Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N2S0066PK8AF161@mail-out.apple.com> for tls@ietf.org; Fri, 21 Mar 2014 07:57:47 -0700 (PDT) X-AuditID: 11807157-f79aa6d0000017b2-46-532c536a0bf2 Received: from orrisroot.apple.com (orrisroot.apple.com [17.128.115.106]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 84.08.06066.A635C235; Fri, 21 Mar 2014 07:57:47 -0700 (PDT) Received: from [17.153.37.122] (unknown [17.153.37.122]) by orrisroot.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N2S002UHK884X40@orrisroot.apple.com> for tls@ietf.org; Fri, 21 Mar 2014 07:57:46 -0700 (PDT) Content-type: multipart/signed; boundary="Apple-Mail=_0F8C088D-B42A-4DC5-BE13-0F1E91849537"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet X-Priority: 3 In-reply-to: <045401cf4514$1c0e5ec0$4001a8c0@gateway.2wire.net> Date: Fri, 21 Mar 2014 10:57:43 -0400 Message-id: References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <532B9B65.4030708@gmail.com> <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com> <045401cf4514$1c0e5ec0$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1874) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUi2FCcpZsdrBNscPYHs8Wn812MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+HpgOXvBp4iKruPBDYynAroYOTkkBEwkHnfNYYewxSQu3FvP 1sXIxSEkMIVJYv3SHjaQhJDAAiaJQ1OSQWxhgVKJP6tus4LYvAJ6EmfO/mIHaWAWmMIoMa/p G9gkNgE1id+T+lghpvJKzGh/ygJicwrYS6xv/g9Uw87BIqAq8UQGJMosYCrx6NsMFoiRNhKT 3j1jh7jhN6vEsQtHwW4QEVCW+LfvJRPESFmJRx+aWCYwCsxCcsYsZGfMAhusLbFs4WtmCFtP 4mXTO6i4qcSTt9vZIGxriZ9zHjFC2IoSU7ofsi9gZF/FKFCUmpNYaaKXWFCQk6qXnJ+7iREc 2IXhOxj/LbM6xCjAwajEw1vJqR0sxJpYVlyZe4hRBWjEow2rLzBKseTl56UqifB+9tEJFuJN SaysSi3Kjy8qzUktPsQozcGiJM771AioUyA9sSQ1OzW1ILUIJsvEwSnVwDjDW8v3W86kVT/D /2zi5rgmPZvD+rxK1DH+WEXH6EYNyb0HK3cq/bDc+nue6c+2QKYphZzKVnNmLY0V2aYdUXVk 0qn2mUZBh1Z1penPPTl5mbjEro2HjidaMnjMyzMq72b/I6HxdENaQiP/SuajrIbBrZu/c+Y/ n9w/IWamr/h1V5PtO8Om8CmxFGckGmoxFxUnAgBsRjyudAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mfYD0p6GGc_BNNyy95DwybeJtcg Cc: tls@ietf.org Subject: Re: [TLS] bootstrapping of constrained devices (was: Re: Should TLS 1.3 use an augmented PAKE by default?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2014 14:57:58 -0000 --Apple-Mail=_0F8C088D-B42A-4DC5-BE13-0F1E91849537 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Tom, Yes, self-signed device certificates are the common implementation = choice and are often generated on the first use/setup of the device = (simpler than doing it in the factory...) On Mar 21, 2014, at 10:44 AM, t.petch wrote: > ----- Original Message ----- > From: "Michael Sweet" > To: "Rene Struik" > Cc: > Sent: Friday, March 21, 2014 12:26 PM >=20 > Rene, >=20 > Installing device certificates during manufacturing is not a simple > process - the factory would need to act as a CA or would need to have = a > supply of certificates that matches whatever identifiers are used by = the > devices. Not to mention how you'd manage revocation if the root was > compromised... >=20 > >=20 > Michael >=20 > In the context of syslog security, some years ago now, the question of > device certificates arose and it was said there that they were quite > common. They would be self-signed, which gives much of the needed > security, while avoiding issues of CA and root compromise. >=20 > Tom Petch >=20 > On Mar 20, 2014, at 9:52 PM, Rene Struik = wrote: >=20 >> Hi Robert: >>=20 >> Wouldn't it be much easier to embed device certificates with > constrained devices at manufacturing? This may do away with need > to store info that is not public on servers. >>=20 >> If you could provide some links to discussions in "IoT community > groups" interested in this, that would help. >>=20 >> Best regards, Rene >>=20 >> =3D=3D >> There is a lot of interest in the IoT community in using some form of > PAKE in conjunction with DTLS (or TLS with EAP) for authenticating > commissioning/bootstrapping of IoT devices onto IoT networks >>=20 >> On 3/20/2014 1:21 PM, Robert Cragie wrote: >>> It should be remembered that TLS is used in places other than web > browsers - the existence of the DICE WG is testament to this. There is = a > lot of interest in the IoT community in using some form of PAKE in > conjunction with DTLS (or TLS with EAP) for authenticating > commissioning/bootstrapping of IoT devices onto IoT networks. I = realise > this is different to the original proposition in this thread but = wanted > to draw this to the attention of the WG nevertheless. >>>=20 >>> Robert >>>=20 >>> On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" > wrote: >>> On 03/20/2014 12:18 PM, Paul Hoffman wrote: >>>> As an important note, you did not define "we" above. A few possible > expansions would be: >>>>=20 >>>> - The TLS WG, where this thread currently lives, does not get to > define Web UI without a charter change. >>>>=20 >>>> - The HTTPbis WG has not asked the TLS WG to take over this work, > nor has it embraced anything like it. >>>>=20 >>>> - The IETF doesn't do this kind of work as a whole body. >>>>=20 >>>> - The IAB (of which none of us are part of the "we") might take the > topic on and suggest ways which the IETF might do the work. >>>=20 >>> yep, thanks for the clarification. I actually meant "we" in the > broad >>> sense of "the community of people who care about making > communications >>> on the web more secure", which includes groups you didn't even > mention >>> above, like web site designers, systems administrators, etc. >>>=20 >>> It's still on-topic here (despite the broad scope implied above) > because >>> the TLS WG does have a role to play, by considering the merits of >>> proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as >>> well as considering alternatives that deal with this particular use > case. >>>=20 >>>>> option (A) is seriously hard, maybe impossible given the state of > the >>>>> web. option (B) is terrible. >>>>=20 >>>> Exactly right, for any value of "we". >>>=20 >>> :( >>>=20 >>> --dkg >>>=20 >>>> -- >> email: rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >=20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair >=20 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_0F8C088D-B42A-4DC5-BE13-0F1E91849537 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMzIxMTQ1NzQ0WjAjBgkqhkiG9w0BCQQxFgQUkTDDqLWTwnlOAAVrFjQLIwuw WkkwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQDCzM9XEA/NhxM+D2QSRx2u+w4RkIKzWG50x3mrGXiUYeunmQ14luqzJ8xf6KL3Ttgwjd0xAdmP tz5//CimGwsvHE1Yqg1u3tDRwHmnnD9Re387pAjzmr9BB18V348EkMph1Xf2TQecbklzwMr+z7jo MZlVpWzQtx763plA7fObIvUt5RnQL5vhsGN9hf259JtkPaMRQJMuZubPwosGXRBW1mr6d8el1EbV b0/m5wX0gYWsjxF8ssCXJ3/EEA2otqPuJp/MgoD2aNiBHKIHEwjM0cyGMasA/poe5kBgjLydYDzh IOgzUirWYZqsmHM8SdQ5ar9EAGKchG25RBnCc0rCAAAAAAAA --Apple-Mail=_0F8C088D-B42A-4DC5-BE13-0F1E91849537-- From nobody Fri Mar 21 08:00:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98591A09B0 for ; Fri, 21 Mar 2014 08:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=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 LAZiJYQMP-3q for ; Fri, 21 Mar 2014 08:00:05 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8C19B1A09A8 for ; Fri, 21 Mar 2014 08:00:05 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id cc10so590939wib.2 for ; Fri, 21 Mar 2014 07:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8WIZZNKxmjg5BIPtnDKkKjhYw2YJtdBnkz1UEWeQ8A0=; b=cKRhhUqAP7F7eRtn4cCVz9TaaVCfG0AWMHOb3bBjNYKgfvAHuLvcitD2HQklO19JSd DvfOODJihDr2jYmL6ZLruL3irYX/PZYxxB/xE3oqN/ZkJ0dABTILM6D/wkBSWE3+1x2a n1O+4Jx/UNjNh9I1ukGbeXB1WCZ6v/pLLGjqvQDPVApjZUm5RH8/9XvE+SykRFVrbb7c MnPSmhrW5vyg6UT51ajtYhiWInfCHGUKyDXkyZl9BW4UZ+Dt6ZK2GXrC56/yw9nDozPi U0I7GzVk5idhzvUBis1Ng+JX6ePvLeXCHlBV52FmtLGtzLZ0X9a3AZRyMdUpRnfd+hY1 ildQ== X-Received: by 10.180.37.178 with SMTP id z18mr3093182wij.46.1395413995694; Fri, 21 Mar 2014 07:59:55 -0700 (PDT) Received: from [192.168.1.99] (188.110.176.95.rev.sfr.net. [95.176.110.188]) by mx.google.com with ESMTPSA id g5sm13878509wjs.8.2014.03.21.07.59.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 07:59:54 -0700 (PDT) Message-ID: <532C53E1.1060302@gmail.com> Date: Fri, 21 Mar 2014 15:59:45 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "t.petch" , Michael Sweet , Rene Struik References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <532B9B65.4030708@gmail.com> <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com> <045401cf4514$1c0e5ec0$4001a8c0@gateway.2wire.net> In-Reply-To: <045401cf4514$1c0e5ec0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zkpADTShAmHYVzFxWxaZCvyi1E0 Cc: tls@ietf.org Subject: Re: [TLS] bootstrapping of constrained devices X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2014 15:00:08 -0000 On 2014-03-21 15:44, t.petch wrote: > ----- Original Message ----- > From: "Michael Sweet" > To: "Rene Struik" > Cc: > Sent: Friday, March 21, 2014 12:26 PM > > Rene, > > Installing device certificates during manufacturing is not a simple > process - the factory would need to act as a CA or would need to have a > supply of certificates that matches whatever identifiers are used by the > devices. Not to mention how you'd manage revocation if the root was > compromised... > > > > Michael > > In the context of syslog security, some years ago now, the question of > device certificates arose and it was said there that they were quite > common. They would be self-signed, which gives much of the needed > security, while avoiding issues of CA and root compromise. In that case the identity would effectively be reduced to a fingerprint (like an SSH key) which could be printed on the outside of the device to facilitate password-free enrollment. This scheme is though not universally applicable because there's a lot of devices where you actually want to know the brand as well including for example the FIDO/Google U2F token so for most devices I suspect you will end-up with a CA anyway. Anders > > Tom Petch > > On Mar 20, 2014, at 9:52 PM, Rene Struik wrote: > >> Hi Robert: >> >> Wouldn't it be much easier to embed device certificates with > constrained devices at manufacturing? This may do away with need > to store info that is not public on servers. >> >> If you could provide some links to discussions in "IoT community > groups" interested in this, that would help. >> >> Best regards, Rene >> >> == >> There is a lot of interest in the IoT community in using some form of > PAKE in conjunction with DTLS (or TLS with EAP) for authenticating > commissioning/bootstrapping of IoT devices onto IoT networks >> >> On 3/20/2014 1:21 PM, Robert Cragie wrote: >>> It should be remembered that TLS is used in places other than web > browsers - the existence of the DICE WG is testament to this. There is a > lot of interest in the IoT community in using some form of PAKE in > conjunction with DTLS (or TLS with EAP) for authenticating > commissioning/bootstrapping of IoT devices onto IoT networks. I realise > this is different to the original proposition in this thread but wanted > to draw this to the attention of the WG nevertheless. >>> >>> Robert >>> >>> On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" > wrote: >>> On 03/20/2014 12:18 PM, Paul Hoffman wrote: >>>> As an important note, you did not define "we" above. A few possible > expansions would be: >>>> >>>> - The TLS WG, where this thread currently lives, does not get to > define Web UI without a charter change. >>>> >>>> - The HTTPbis WG has not asked the TLS WG to take over this work, > nor has it embraced anything like it. >>>> >>>> - The IETF doesn't do this kind of work as a whole body. >>>> >>>> - The IAB (of which none of us are part of the "we") might take the > topic on and suggest ways which the IETF might do the work. >>> >>> yep, thanks for the clarification. I actually meant "we" in the > broad >>> sense of "the community of people who care about making > communications >>> on the web more secure", which includes groups you didn't even > mention >>> above, like web site designers, systems administrators, etc. >>> >>> It's still on-topic here (despite the broad scope implied above) > because >>> the TLS WG does have a role to play, by considering the merits of >>> proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as >>> well as considering alternatives that deal with this particular use > case. >>> >>>>> option (A) is seriously hard, maybe impossible given the state of > the >>>>> web. option (B) is terrible. >>>> >>>> Exactly right, for any value of "we". >>> >>> :( >>> >>> --dkg >>> >>>> -- >> email: rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Mar 21 08:12:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B571A09BD for ; Fri, 21 Mar 2014 08:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.448 X-Spam-Level: X-Spam-Status: No, score=-9.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.547, 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 VylR_A_IXhKe for ; Fri, 21 Mar 2014 08:12:15 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 42BD41A09B9 for ; Fri, 21 Mar 2014 08:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6000; q=dns/txt; s=iport; t=1395414726; x=1396624326; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TdeoUcfvyiFhuPImi12XEwcEv1UfWh8Y4huwWmjrvms=; b=QDOJb4NJ/ixBKpl/r4qjDyupt2CdLBKADW6LeN0NS+FcI6ellTCMj7si 6rOWBN6+Lm8CNcndTbMI8qrKWceRqi9kx0XK2zYLqkRkyJET+8Yt6vYzv nmAH8BrHKsycUaAk+PxcjlVvavZE1h7662tHvLsLCL8wItA/mmwdHTHd9 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAOBVLFOtJXG+/2dsb2JhbABWA4MGO1e7JYc0gRUWdIIlAQEBAwEBAQFrCwUHBAIBCA4HAQIjCyEGCyUCBA4FFIdRAwkIDchSDYcKF4xSgTUBEQEODyMQBxGDE4EUBItkiniBbYEyizaFSYFvgT6BawcXIg X-IronPort-AV: E=Sophos;i="4.97,704,1389744000"; d="scan'208";a="29342530" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-4.cisco.com with ESMTP; 21 Mar 2014 15:12:05 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2LFC5m4000648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 15:12:05 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.3]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 10:12:05 -0500 From: "Max Pritikin (pritikin)" To: Michael Sweet Thread-Topic: [TLS] bootstrapping of constrained devices (was: Re: Should TLS 1.3 use an augmented PAKE by default?) Thread-Index: AQHPRKhFJRJU1RplZ0OuMVZFIQAhSJrry/IA///UmYKAAFXIgIAABCQA Date: Fri, 21 Mar 2014 15:12:04 +0000 Message-ID: <8CEDB637-22E1-4405-B554-51F3171784B5@cisco.com> References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <532B9B65.4030708@gmail.com> <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com> <045401cf4514$1c0e5ec0$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.95.205] Content-Type: text/plain; charset="Windows-1252" Content-ID: <97E5F6155E247F44988277A770D1D8EB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VSYshu4yo-fc19MVj_MW0alsNDQ Cc: "tls@ietf.org" Subject: Re: [TLS] bootstrapping of constrained devices (was: Re: Should TLS 1.3 use an augmented PAKE by default?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2014 15:12:21 -0000 Generating keys =93on the first use/setup=94 of the device means that first= connection is unsecured. I have serious concerns about that! Manufacturing generated credentials can be integrated into the sales proces= s. I agree with Ander=92s that binding other information to the credential = is a good thing, but even if its a raw key pair (=93self-signed=94) the has= h can still be printed onto a barcode or distributed electronically as part= of the bill of sale.=20 I think the best compromise is a manufacturer CA method that can be as ligh= tweight as the manufacturer wishes. If they want to manage their CA keys po= orly because of the perceived complexity they can do so. Other manufacturer= s can provide a more secure product. The relying parties (and the standards= they rely on) can expect real certificate chains and seamlessly support pr= oducts with security goals. They can tell, based on the issuing CA, somethi= ng about the constrained device.=20 Don=92t forget too that constrained devices need a mechanism to ensure they= =92re bootstrapping into the correct network/management-infrastructure. To = do so they need some root of trust installed prior to deployment. I=92d sug= gest this is the same root of trust they use for software upgrades although= for constrained devices perhaps many feel updates are out-of-scope.=20 - max On Mar 21, 2014, at 8:57 AM, Michael Sweet wrote: > Tom, >=20 > Yes, self-signed device certificates are the common implementation choice= and are often generated on the first use/setup of the device (simpler than= doing it in the factory...) >=20 >=20 > On Mar 21, 2014, at 10:44 AM, t.petch wrote: >=20 >> ----- Original Message ----- >> From: "Michael Sweet" >> To: "Rene Struik" >> Cc: >> Sent: Friday, March 21, 2014 12:26 PM >>=20 >> Rene, >>=20 >> Installing device certificates during manufacturing is not a simple >> process - the factory would need to act as a CA or would need to have a >> supply of certificates that matches whatever identifiers are used by the >> devices. Not to mention how you'd manage revocation if the root was >> compromised... >>=20 >> >>=20 >> Michael >>=20 >> In the context of syslog security, some years ago now, the question of >> device certificates arose and it was said there that they were quite >> common. They would be self-signed, which gives much of the needed >> security, while avoiding issues of CA and root compromise. >>=20 >> Tom Petch >>=20 >> On Mar 20, 2014, at 9:52 PM, Rene Struik wrote: >>=20 >>> Hi Robert: >>>=20 >>> Wouldn't it be much easier to embed device certificates with >> constrained devices at manufacturing? This may do away with need >> to store info that is not public on servers. >>>=20 >>> If you could provide some links to discussions in "IoT community >> groups" interested in this, that would help. >>>=20 >>> Best regards, Rene >>>=20 >>> =3D=3D >>> There is a lot of interest in the IoT community in using some form of >> PAKE in conjunction with DTLS (or TLS with EAP) for authenticating >> commissioning/bootstrapping of IoT devices onto IoT networks >>>=20 >>> On 3/20/2014 1:21 PM, Robert Cragie wrote: >>>> It should be remembered that TLS is used in places other than web >> browsers - the existence of the DICE WG is testament to this. There is a >> lot of interest in the IoT community in using some form of PAKE in >> conjunction with DTLS (or TLS with EAP) for authenticating >> commissioning/bootstrapping of IoT devices onto IoT networks. I realise >> this is different to the original proposition in this thread but wanted >> to draw this to the attention of the WG nevertheless. >>>>=20 >>>> Robert >>>>=20 >>>> On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" >> wrote: >>>> On 03/20/2014 12:18 PM, Paul Hoffman wrote: >>>>> As an important note, you did not define "we" above. A few possible >> expansions would be: >>>>>=20 >>>>> - The TLS WG, where this thread currently lives, does not get to >> define Web UI without a charter change. >>>>>=20 >>>>> - The HTTPbis WG has not asked the TLS WG to take over this work, >> nor has it embraced anything like it. >>>>>=20 >>>>> - The IETF doesn't do this kind of work as a whole body. >>>>>=20 >>>>> - The IAB (of which none of us are part of the "we") might take the >> topic on and suggest ways which the IETF might do the work. >>>>=20 >>>> yep, thanks for the clarification. I actually meant "we" in the >> broad >>>> sense of "the community of people who care about making >> communications >>>> on the web more secure", which includes groups you didn't even >> mention >>>> above, like web site designers, systems administrators, etc. >>>>=20 >>>> It's still on-topic here (despite the broad scope implied above) >> because >>>> the TLS WG does have a role to play, by considering the merits of >>>> proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as >>>> well as considering alternatives that deal with this particular use >> case. >>>>=20 >>>>>> option (A) is seriously hard, maybe impossible given the state of >> the >>>>>> web. option (B) is terrible. >>>>>=20 >>>>> Exactly right, for any value of "we". >>>>=20 >>>> :( >>>>=20 >>>> --dkg >>>>=20 >>>>> -- >>> email: rstruik.ext@gmail.com | Skype: rstruik >>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>=20 >> _________________________________________________________ >> Michael Sweet, Senior Printing System Engineer, PWG Chair >>=20 >=20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Mar 21 08:15:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A3B1A09BD for ; Fri, 21 Mar 2014 08:15:10 -0700 (PDT) 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, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_Pf_cBiahG6 for ; Fri, 21 Mar 2014 08:15:09 -0700 (PDT) Received: from nm20-vm2.access.bullet.mail.gq1.yahoo.com (nm20-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0491F1A09BC for ; Fri, 21 Mar 2014 08:15:08 -0700 (PDT) Received: from [216.39.60.165] by nm20.access.bullet.mail.gq1.yahoo.com with NNFMP; 21 Mar 2014 15:14:59 -0000 Received: from [67.195.22.113] by tm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 21 Mar 2014 15:14:59 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.gq1.yahoo.com with NNFMP; 21 Mar 2014 15:14:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1395414899; bh=P9qjcf6o+CiteRTub6f0PIieFDd6W3m0Xuf5+sUlUhg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=aOEgJHm4peTAf6MTK1ioveBBpA1yav5yU4zo+sRiGWBIppo3dUr2dGvSDKL+x0exEcpBM5PvIY11tMoFuxcjw/85Py+VcfJre1RbC3h4Vy4nRfrWPiCNeCaT4q/xBJ0uCocmNF8OlFsdpI0Ji18g1JBDnVayLUPLc6WpvG9eT5I= X-Yahoo-Newman-Id: 727800.65713.bm@smtp115.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 0bYL7v4VM1lBJ8woxeABNrDAdUFuyoh0b3vBpu3dCDEjwUY hy0JSGvhjFA95_M07hLg_Ev9mGk9gpX.fTnQpymAgrwMd9iquWxEZo0eH_H5 RU4qsvwKaWOPzAiN4PI0_GTJWgZiAOBYiaWvsou3UfOydfSwABikyZaCi.q1 LQ_Xc0Ci2_vBOAmBcCOFxxKWpX6Z2WEJbr7dU6dY2ClvC7a5wRPrIkw4UEdz rNEy1ywduzZHWL4hFFxc93mR2ruO0sJIgNqrK5r4nY.YZwUMa9JM4hqBwl9M jeN9F7HeLabbCS8qva.wfEUNYlCJpBC1n_ZJ1bIDQCtjc.S.EuNyR9DfLk0p VkdfBVokSeXNRdCpxgsXAlWXMZlokLy9mNp.C0PPlHW9n48UBwouafaknGg9 yVbP_0NtAY3nIuNj616Z3RHJsI3IZ1iFjCdWacpyurJtRlEJxYlpbsCG5Qh7 ob3ahM5jM7AyZO5qdNCVSpVarTHfL6xX.cvK9gm.fqkDP.PHnYab.SBQPLDY 4SlmgtxyWZQjLRlFOsZlmrJH90Z0Jc4yzwYsG3ZClWUwP7gXZ0PVeLyKlzYX k96xToMh7kQ-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@108.225.234.240 with plain [67.195.15.5]) by smtp115.sbc.mail.gq1.yahoo.com with SMTP; 21 Mar 2014 08:14:59 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Fri, 21 Mar 2014 08:14:56 -0700 From: Don Sturek To: Michael Sweet , "t.petch" Message-ID: Thread-Topic: [TLS] bootstrapping of constrained devices (was: Re: Should TLS 1.3 use an augmented PAKE by default?) References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <532B9B65.4030708@gmail.com> <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com> <045401cf4514$1c0e5ec0$4001a8c0@gateway.2wire.net> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/slOGkBa_2wFhDyRGH-Zy0mhuWwQ Cc: tls@ietf.org Subject: Re: [TLS] bootstrapping of constrained devices (was: Re: Should TLS 1.3 use an augmented PAKE by default?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2014 15:15:11 -0000 Hi Michael, One approach we used for Smart Energy Profile 2.0 (now IEEE 2030.5) is to use IEEE 802.1ar certificates. These are secure device identity certificates just for authentication. We don't support OCP on these certificates, however, it is possible to use CRL. The purpose is to simply authenticate the device. If authorization is wanted, an operational certificate or a whitelist/blacklist can be used. Don On 3/21/14 7:57 AM, "Michael Sweet" wrote: >Tom, > >Yes, self-signed device certificates are the common implementation choice >and are often generated on the first use/setup of the device (simpler >than doing it in the factory...) > > >On Mar 21, 2014, at 10:44 AM, t.petch wrote: > >> ----- Original Message ----- >> From: "Michael Sweet" >> To: "Rene Struik" >> Cc: >> Sent: Friday, March 21, 2014 12:26 PM >> >> Rene, >> >> Installing device certificates during manufacturing is not a simple >> process - the factory would need to act as a CA or would need to have a >> supply of certificates that matches whatever identifiers are used by the >> devices. Not to mention how you'd manage revocation if the root was >> compromised... >> >> >> >> Michael >> >> In the context of syslog security, some years ago now, the question of >> device certificates arose and it was said there that they were quite >> common. They would be self-signed, which gives much of the needed >> security, while avoiding issues of CA and root compromise. >> >> Tom Petch >> >> On Mar 20, 2014, at 9:52 PM, Rene Struik wrote: >> >>> Hi Robert: >>> >>> Wouldn't it be much easier to embed device certificates with >> constrained devices at manufacturing? This may do away with need >> to store info that is not public on servers. >>> >>> If you could provide some links to discussions in "IoT community >> groups" interested in this, that would help. >>> >>> Best regards, Rene >>> >>> == >>> There is a lot of interest in the IoT community in using some form of >> PAKE in conjunction with DTLS (or TLS with EAP) for authenticating >> commissioning/bootstrapping of IoT devices onto IoT networks >>> >>> On 3/20/2014 1:21 PM, Robert Cragie wrote: >>>> It should be remembered that TLS is used in places other than web >> browsers - the existence of the DICE WG is testament to this. There is a >> lot of interest in the IoT community in using some form of PAKE in >> conjunction with DTLS (or TLS with EAP) for authenticating >> commissioning/bootstrapping of IoT devices onto IoT networks. I realise >> this is different to the original proposition in this thread but wanted >> to draw this to the attention of the WG nevertheless. >>>> >>>> Robert >>>> >>>> On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" >> wrote: >>>> On 03/20/2014 12:18 PM, Paul Hoffman wrote: >>>>> As an important note, you did not define "we" above. A few possible >> expansions would be: >>>>> >>>>> - The TLS WG, where this thread currently lives, does not get to >> define Web UI without a charter change. >>>>> >>>>> - The HTTPbis WG has not asked the TLS WG to take over this work, >> nor has it embraced anything like it. >>>>> >>>>> - The IETF doesn't do this kind of work as a whole body. >>>>> >>>>> - The IAB (of which none of us are part of the "we") might take the >> topic on and suggest ways which the IETF might do the work. >>>> >>>> yep, thanks for the clarification. I actually meant "we" in the >> broad >>>> sense of "the community of people who care about making >> communications >>>> on the web more secure", which includes groups you didn't even >> mention >>>> above, like web site designers, systems administrators, etc. >>>> >>>> It's still on-topic here (despite the broad scope implied above) >> because >>>> the TLS WG does have a role to play, by considering the merits of >>>> proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as >>>> well as considering alternatives that deal with this particular use >> case. >>>> >>>>>> option (A) is seriously hard, maybe impossible given the state of >> the >>>>>> web. option (B) is terrible. >>>>> >>>>> Exactly right, for any value of "we". >>>> >>>> :( >>>> >>>> --dkg >>>> >>>>> -- >>> email: rstruik.ext@gmail.com | Skype: rstruik >>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> >> _________________________________________________________ >> Michael Sweet, Senior Printing System Engineer, PWG Chair >> > >_________________________________________________________ >Michael Sweet, Senior Printing System Engineer, PWG Chair > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From nobody Fri Mar 21 08:18:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EFD1A09B9 for ; Fri, 21 Mar 2014 08:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs7-bAYSnEiB for ; Fri, 21 Mar 2014 08:18:33 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan23.extendcp.co.uk [176.32.226.69]) by ietfa.amsl.com (Postfix) with ESMTP id D12291A0128 for ; Fri, 21 Mar 2014 08:18:32 -0700 (PDT) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan5.hi.local) by mailscan-g66.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1WR1DB-0004Em-FG; Fri, 21 Mar 2014 15:18:21 +0000 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan5.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1WR1D9-00087i-Hi; Fri, 21 Mar 2014 15:18:21 +0000 Received: from host86-151-9-208.range86-151.btcentralplus.com ([86.151.9.208] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1WR1D8-0005Jl-MD; Fri, 21 Mar 2014 15:18:19 +0000 Message-ID: <532C5867.2050704@gridmerge.com> Date: Fri, 21 Mar 2014 15:19:03 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Rene Struik References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <532B9B65.4030708@gmail.com> <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com> In-Reply-To: <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040003060001020800080803" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SjIkUOWFGO_U62mONlsh1YMkT_A Cc: "tls@ietf.org" Subject: Re: [TLS] bootstrapping of constrained devices X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.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, 21 Mar 2014 15:18:37 -0000 This is a cryptographically signed message in MIME format. --------------ms040003060001020800080803 Content-Type: multipart/alternative; boundary="------------050103070900010809030702" This is a multi-part message in MIME format. --------------050103070900010809030702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Rene, There is certainly a place for device certificates but they are=20 generally quite expensive in terms of the infrastructure needed to=20 support them as Michael points out. There are no specific links I can point to but the use case is using=20 relatively short codes which are put into e.g. a home router through a=20 web interface to provide steering, a basis for authenticating another=20 device onto the network and a secure channel for delivery of=20 configuration/bootstrapping information. WPS PIN is an example of this=20 (notwithstanding its implementational flaws). Using TLS/DTLS as a basis=20 provides the possibility of reuse at the application layer, which is a=20 bonus for the relatively constrained devices generally considered to be=20 in use in the IoT. Robert On 21/03/2014 12:26 PM, Michael Sweet wrote: > Rene, > > Installing device certificates during manufacturing is not a simple=20 > process - the factory would need to act as a CA or would need to have=20 > a supply of certificates that matches whatever identifiers are used by = > the devices. Not to mention how you'd manage revocation if the root=20 > was compromised... > > > On Mar 20, 2014, at 9:52 PM, Rene Struik > wrote: > >> Hi Robert: >> >> Wouldn't it be much easier to embed device certificates with=20 >> constrained devices at manufacturing? This may do away with need to=20 >> store info that is not public on servers. >> >> If you could provide some links to discussions in "IoT community=20 >> groups" interested in this, that would help. >> >> Best regards, Rene >> >> =3D=3D >> There is a lot of interest in the IoT community in using some form of = >> PAKE in conjunction with DTLS (or TLS with EAP) for authenticating=20 >> commissioning/bootstrapping of IoT devices onto IoT networks >> >> On 3/20/2014 1:21 PM, Robert Cragie wrote: >>> >>> It should be remembered that TLS is used in places other than web=20 >>> browsers - the existence of the DICE WG is testament to this. There=20 >>> is a lot of interest in the IoT community in using some form of PAKE = >>> in conjunction with DTLS (or TLS with EAP) for authenticating=20 >>> commissioning/bootstrapping of IoT devices onto IoT networks. I=20 >>> realise this is different to the original proposition in this thread = >>> but wanted to draw this to the attention of the WG nevertheless. >>> >>> Robert >>> >>> On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" >> > wrote: >>> >>> On 03/20/2014 12:18 PM, Paul Hoffman wrote: >>> > As an important note, you did not define "we" above. A few >>> possible expansions would be: >>> > >>> > - The TLS WG, where this thread currently lives, does not get >>> to define Web UI without a charter change. >>> > >>> > - The HTTPbis WG has not asked the TLS WG to take over this >>> work, nor has it embraced anything like it. >>> > >>> > - The IETF doesn't do this kind of work as a whole body. >>> > >>> > - The IAB (of which none of us are part of the "we") might >>> take the topic on and suggest ways which the IETF might do the wo= rk. >>> >>> yep, thanks for the clarification. I actually meant "we" in the >>> broad >>> sense of "the community of people who care about making >>> communications >>> on the web more secure", which includes groups you didn't even >>> mention >>> above, like web site designers, systems administrators, etc. >>> >>> It's still on-topic here (despite the broad scope implied above) >>> because >>> the TLS WG does have a role to play, by considering the merits of= >>> proposals like http://tools.ietf.org/html/draft-thomson-tls-care,= as >>> well as considering alternatives that deal with this particular >>> use case. >>> >>> >> option (A) is seriously hard, maybe impossible given the >>> state of the >>> >> web. option (B) is terrible. >>> > >>> > Exactly right, for any value of "we". >>> >>> :( >>> >>> --dkg >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> >> >> --=20 >> 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 > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > --------------050103070900010809030702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rene,

There is certainly a place for device certificates but they are generally quite expensive in terms of the infrastructure needed to support them as Michael points out.

There are no specific links I can point to but the use case is using relatively short codes which are put into e.g. a home router through a web interface to provide steering, a basis for authenticating another device onto the network and a secure channel for delivery of configuration/bootstrapping information. WPS PIN is an example of this (notwithstanding its implementational flaws). Using TLS/DTLS as a basis provides the possibility of reuse at the application layer, which is a bonus for the relatively constrained devices generally considered to be in use in the IoT.

Robert

On 21/03/2014 12:26 PM, Michael Sweet wrote:
Rene,

Installing device certificates during manufacturing is not a simple process - the factory would need to act as a CA or would need to have a supply of certificates that matches whatever identifiers are used by the devices.  Not to mention how you= 'd manage revocation if the root was compromised...


On Mar 20, 2014, at 9:52 PM, Rene Struik <rstruik.ext@gmail.com> wrote:

Hi Robert:

Wouldn't it be much easier to embed device certificates with constrained devices at manufacturing? This may do away with need to store info that is not public on servers.

If you could provide some links to discussions in "IoT community groups" interested in this, that would help.
Best regards, Rene

=3D=3D
There is a lot of interest in the IoT community in using some form of PAKE in conjunction with DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT devices onto IoT networks

On 3/20/2014 1:21 PM, Robert Cragie wrote:

It should be remembered that TLS is used i= n places other than web browsers - the existence of the DICE WG is testament to this. There is a lot of interest in the IoT community in using some form of PAKE in conjunction with DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT devices onto IoT networks. I realise this is different to the original proposition in this thread but wanted to draw this to the attention of the WG nevertheless.

Robert

On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" <dkg@fifthhorsem= an.net> wrote:
On 03/20/2014 12:18 PM, Paul Hoffman wrote:
> As an important note, you did not define "we" above. A few possible expansions would be:
>
> - The TLS WG, where this thread currently lives, does not get to define Web UI without a charter change.
>
> - The HTTPbis WG has not asked the TLS WG to take over this work, nor has it embraced anything like it.
>
> - The IETF doesn't do this kind of work as a whole body.
>
> - The IAB (of which none of us are part of the "we") might take the topic on and suggest ways which the IETF might do the work.

yep, thanks for the clarification.  I actually m= eant "we" in the broad
sense of "the community of people who care about making communications
on the web more secure", which includes groups you didn't even mention
above, like web site designers, systems administrators, etc.

It's still on-topic here (despite the broad scope implied above) because
the TLS WG does have a role to play, by considering the merits of
proposals like http://tools.ietf.org/html/draft-= thomson-tls-care, as
well as considering alternatives that deal with this particular use case.

>> option (A) is seriously hard, maybe impossible given the state of the
>> web.  option (B) is terrible.
>
> Exactly right, for any value of "we".

:(

        --dkg


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



__________________________________________=
_____
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listin=
fo/tls



--=20
email: rstruik.ext@gmail.com | Skype: rst=
ruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
TLS mailing list
TLS@= ietf.org
https://www.ietf.org/mailman/listinfo/tls

_________= ________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--------------050103070900010809030702-- --------------ms040003060001020800080803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDAzMjExNTE5MDNaMCMGCSqGSIb3DQEJBDEWBBQ4yqSaTsE6lQg5aIacH5cdssi1XzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAGQnT2TUVEO2DFLa6U/847cdtY1XTsMDEQebuWDUEWhbutuu AsUzLSsc62+Jj2UG5G2lOdrVxcAZfjPtHlu2wZGSe1P3KhSbE2JgmplrSFLblVvMbWAFjTvD /zIhbFo93nc8/Yy+6HwjoSt3wFWEIBXFXZjW53K/xk53fZm9OdKL7KJcvLD5SfaIIlOeHc7V Lsx5IwcTBK9lPMnzDjGERGfNFWRMM7EpuKb0DTLzWn1G+xykm3uiJuavp7ESmenKL6Yp0oiX VXFOr2NHVYehadcrLVqqJFQlPse9/W1nZKd6U5ivmIm5GcjbLJhYCO4jMKCMfePL/VS/mn+b iWoDkksAAAAAAAA= --------------ms040003060001020800080803-- From nobody Fri Mar 21 08:49:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C321A09C8 for ; Fri, 21 Mar 2014 08:49:16 -0700 (PDT) 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 65_a2JH5QOMd for ; Fri, 21 Mar 2014 08:49:14 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B2FBF1A09C0 for ; Fri, 21 Mar 2014 08:49:11 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 9so6658911ykp.1 for ; Fri, 21 Mar 2014 08:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a7+gZVrPg0gy8DBJ4/VpjwYRXgMxtxjTaVsEOD7QURs=; b=HHzvCifDXpEpzljqQs3f+V0359mHDnp/HlM6tcO7AFkWihsgF6vlLonE2Vy16PLYMg 8YygfvyMCK29hDwzC+4Qnbw/L+9RXOumG02140bEo9wcX3Xk2y2OCYJ1scMSBmIp1qw6 4tdny2rYmDwQcUxGtueoa4o1F9cCqDv9TdiAHRnXAYuYe7Z8zqltxNvLlFrYuZOgnjiz kNCmAmb6ZzxAD+O/cgiiImSkcBdcW3+RR98RKijfTc2ellWGEbCfpjdOqolGXI6/Tmzk dNiE+hpgxmWtFZ4s4bKkYbmljZT/emZy4yaBztoyVuZM4iGgbad20nfQh6BYXVUiO9EA /WIQ== MIME-Version: 1.0 X-Received: by 10.236.142.198 with SMTP id i46mr67763120yhj.66.1395416942220; Fri, 21 Mar 2014 08:49:02 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Fri, 21 Mar 2014 08:49:02 -0700 (PDT) In-Reply-To: <532C5867.2050704@gridmerge.com> References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <532B9B65.4030708@gmail.com> <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com> <532C5867.2050704@gridmerge.com> Date: Fri, 21 Mar 2014 08:49:02 -0700 Message-ID: From: Watson Ladd To: robert.cragie@gridmerge.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IYkiT8l7131vzq15c7IPGpiLx2Q Cc: "tls@ietf.org" Subject: Re: [TLS] bootstrapping of constrained devices X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2014 15:49:16 -0000 On Fri, Mar 21, 2014 at 8:19 AM, Robert Cragie wrote: > Hi Rene, > > There is certainly a place for device certificates but they are generally > quite expensive in terms of the infrastructure needed to support them as > Michael points out. > > There are no specific links I can point to but the use case is using > relatively short codes which are put into e.g. a home router through a web > interface to provide steering, a basis for authenticating another device > onto the network and a secure channel for delivery of > configuration/bootstrapping information. WPS PIN is an example of this > (notwithstanding its implementational flaws). Using TLS/DTLS as a basis > provides the possibility of reuse at the application layer, which is a bonus > for the relatively constrained devices generally considered to be in use in > the IoT. There are drafts for AugPAKE and J-PAKE that could be done as RFCs relatively quickly, The reason we haven't modernized the PAKEs is the one scheme that was presented, Dragonfly, wasn't good enough. I don't see any reason for either AugPAKE or J-PAKE to go through. Granted, I've not studied them in enough detail quite yet, but they look good so far. Sincerely, Watson Ladd > > Robert > > > On 21/03/2014 12:26 PM, Michael Sweet wrote: > > Rene, > > Installing device certificates during manufacturing is not a simple process > - the factory would need to act as a CA or would need to have a supply of > certificates that matches whatever identifiers are used by the devices. Not > to mention how you'd manage revocation if the root was compromised... > > > On Mar 20, 2014, at 9:52 PM, Rene Struik wrote: > > Hi Robert: > > Wouldn't it be much easier to embed device certificates with constrained > devices at manufacturing? This may do away with need to store info that is > not public on servers. > > If you could provide some links to discussions in "IoT community groups" > interested in this, that would help. > > Best regards, Rene > > == > There is a lot of interest in the IoT community in using some form of PAKE > in conjunction with DTLS (or TLS with EAP) for authenticating > commissioning/bootstrapping of IoT devices onto IoT networks > > On 3/20/2014 1:21 PM, Robert Cragie wrote: > > It should be remembered that TLS is used in places other than web browsers - > the existence of the DICE WG is testament to this. There is a lot of > interest in the IoT community in using some form of PAKE in conjunction with > DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT > devices onto IoT networks. I realise this is different to the original > proposition in this thread but wanted to draw this to the attention of the > WG nevertheless. > > Robert > > On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" wrote: >> >> On 03/20/2014 12:18 PM, Paul Hoffman wrote: >> > As an important note, you did not define "we" above. A few possible >> > expansions would be: >> > >> > - The TLS WG, where this thread currently lives, does not get to define >> > Web UI without a charter change. >> > >> > - The HTTPbis WG has not asked the TLS WG to take over this work, nor >> > has it embraced anything like it. >> > >> > - The IETF doesn't do this kind of work as a whole body. >> > >> > - The IAB (of which none of us are part of the "we") might take the >> > topic on and suggest ways which the IETF might do the work. >> >> yep, thanks for the clarification. I actually meant "we" in the broad >> sense of "the community of people who care about making communications >> on the web more secure", which includes groups you didn't even mention >> above, like web site designers, systems administrators, etc. >> >> It's still on-topic here (despite the broad scope implied above) because >> the TLS WG does have a role to play, by considering the merits of >> proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as >> well as considering alternatives that deal with this particular use case. >> >> >> option (A) is seriously hard, maybe impossible given the state of the >> >> web. option (B) is terrible. >> > >> > Exactly right, for any value of "we". >> >> :( >> >> --dkg >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > _______________________________________________ > > 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 > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Mar 21 09:04:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE081A09E8 for ; Fri, 21 Mar 2014 09:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aAJ3ZhztqxUT for ; Fri, 21 Mar 2014 09:04:09 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0721A09EE for ; Fri, 21 Mar 2014 09:04:08 -0700 (PDT) Received: from mail62-co9-R.bigfish.com (10.236.132.249) by CO9EHSOBE037.bigfish.com (10.236.130.100) with Microsoft SMTP Server id 14.1.225.22; Fri, 21 Mar 2014 16:03:59 +0000 Received: from mail62-co9 (localhost [127.0.0.1]) by mail62-co9-R.bigfish.com (Postfix) with ESMTP id CAC13A803E9; Fri, 21 Mar 2014 16:03:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.5; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0310HT004.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I1432I7f52h1447Idb82hzz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hz8dhz8275ch1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2052h20b3h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh1155h) Received-SPF: pass (mail62-co9: domain of rhul.ac.uk designates 157.56.248.5 as permitted sender) client-ip=157.56.248.5; envelope-from=Kenny.Paterson@rhul.ac.uk; helo=AMSPRD0310HT004.eurprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019001)(6009001)(428001)(51704005)(24454002)(51914003)(479174003)(377454003)(199002)(189002)(87266001)(80022001)(92566001)(83716003)(53806001)(325944007)(66066001)(65816001)(87936001)(76482001)(33656001)(81542001)(74876001)(83072002)(76796001)(54316002)(92726001)(51856001)(95666003)(54356001)(2656002)(46102001)(69226001)(94316002)(93136001)(79102001)(93516002)(63696002)(20776003)(49866001)(94946001)(86362001)(85306002)(1411001)(59766001)(97186001)(77982001)(56776001)(47446002)(19580395003)(74366001)(19580405001)(74482001)(83322001)(82746002)(50986001)(81816001)(31966008)(74662001)(74502001)(4396001)(80976001)(15975445006)(74706001)(81342001)(76786001)(36756003)(95416001)(561944002)(47736001)(85852003)(47976001)(15202345003)(56816005)(90146001)(81686001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB383; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:F4DBF1F5.AFFA67E0.BFF461BB.C2E5F541.205E1; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail62-co9 (localhost.localdomain [127.0.0.1]) by mail62-co9 (MessageSwitch) id 1395417837501571_14211; Fri, 21 Mar 2014 16:03:57 +0000 (UTC) Received: from CO9EHSMHS005.bigfish.com (unknown [10.236.132.243]) by mail62-co9.bigfish.com (Postfix) with ESMTP id 6BDD46A0076; Fri, 21 Mar 2014 16:03:57 +0000 (UTC) Received: from AMSPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.5) by CO9EHSMHS005.bigfish.com (10.236.130.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 21 Mar 2014 16:03:57 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by AMSPRD0310HT004.eurprd03.prod.outlook.com (10.255.40.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 21 Mar 2014 16:03:51 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) with Microsoft SMTP Server (TLS) id 15.0.898.11; Fri, 21 Mar 2014 16:03:50 +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.0898.005; Fri, 21 Mar 2014 16:03:50 +0000 From: "Paterson, Kenny" To: Watson Ladd Thread-Topic: [TLS] bootstrapping of constrained devices Thread-Index: AQHPRRjdGRG2NbhO+U2QyRiSBBsmfJrrr/cAgAAEITA= Date: Fri, 21 Mar 2014 16:03:49 +0000 Message-ID: References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <532B9B65.4030708@gmail.com> <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com> <532C5867.2050704@gridmerge.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.42.226.146] x-forefront-prvs: 0157DEB61B Content-Type: text/plain; charset="us-ascii" 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% Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0OsZvvgxuWhphP46hR-uaVmDYsM Cc: "tls@ietf.org" Subject: Re: [TLS] bootstrapping of constrained devices X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2014 16:04:13 -0000 > On 21 Mar 2014, at 15:50, "Watson Ladd" wrote: >=20 > On Fri, Mar 21, 2014 at 8:19 AM, Robert Cragie > wrote: >> Hi Rene, >>=20 >> There is certainly a place for device certificates but they are generall= y >> quite expensive in terms of the infrastructure needed to support them as >> Michael points out. >>=20 >> There are no specific links I can point to but the use case is using >> relatively short codes which are put into e.g. a home router through a w= eb >> interface to provide steering, a basis for authenticating another device >> onto the network and a secure channel for delivery of >> configuration/bootstrapping information. WPS PIN is an example of this >> (notwithstanding its implementational flaws). Using TLS/DTLS as a basis >> provides the possibility of reuse at the application layer, which is a b= onus >> for the relatively constrained devices generally considered to be in use= in >> the IoT. >=20 > There are drafts for AugPAKE and J-PAKE that could be done as RFCs > relatively quickly, The reason we haven't modernized the PAKEs is the > one scheme that was presented, Dragonfly, wasn't good enough. I don't > see any reason for either AugPAKE or J-PAKE to go through. >=20 > Granted, I've not studied them in enough detail quite yet, but they > look good so far. >=20 As far as I am aware, there's no complete formal security analysis of J-PAK= E. There are claims in the original paper about the security conferred by t= he use of ZK proofs, and some informal security analysis (stated as theorem= s and proofs), but, as far as I know, there's no security proof using a rec= ognised PAKE security model.=20 Cheers Kenny > Sincerely, > Watson Ladd >=20 >>=20 >> Robert >>=20 >>=20 >> On 21/03/2014 12:26 PM, Michael Sweet wrote: >>=20 >> Rene, >>=20 >> Installing device certificates during manufacturing is not a simple proc= ess >> - the factory would need to act as a CA or would need to have a supply o= f >> certificates that matches whatever identifiers are used by the devices. = Not >> to mention how you'd manage revocation if the root was compromised... >>=20 >>=20 >> On Mar 20, 2014, at 9:52 PM, Rene Struik wrote: >>=20 >> Hi Robert: >>=20 >> Wouldn't it be much easier to embed device certificates with constrained >> devices at manufacturing? This may do away with need to store info that = is >> not public on servers. >>=20 >> If you could provide some links to discussions in "IoT community groups" >> interested in this, that would help. >>=20 >> Best regards, Rene >>=20 >> =3D=3D >> There is a lot of interest in the IoT community in using some form of PA= KE >> in conjunction with DTLS (or TLS with EAP) for authenticating >> commissioning/bootstrapping of IoT devices onto IoT networks >>=20 >> On 3/20/2014 1:21 PM, Robert Cragie wrote: >>=20 >> It should be remembered that TLS is used in places other than web browse= rs - >> the existence of the DICE WG is testament to this. There is a lot of >> interest in the IoT community in using some form of PAKE in conjunction = with >> DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of= IoT >> devices onto IoT networks. I realise this is different to the original >> proposition in this thread but wanted to draw this to the attention of t= he >> WG nevertheless. >>=20 >> Robert >>=20 >>> On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" wro= te: >>>=20 >>>> On 03/20/2014 12:18 PM, Paul Hoffman wrote: >>>> As an important note, you did not define "we" above. A few possible >>>> expansions would be: >>>>=20 >>>> - The TLS WG, where this thread currently lives, does not get to defin= e >>>> Web UI without a charter change. >>>>=20 >>>> - The HTTPbis WG has not asked the TLS WG to take over this work, nor >>>> has it embraced anything like it. >>>>=20 >>>> - The IETF doesn't do this kind of work as a whole body. >>>>=20 >>>> - The IAB (of which none of us are part of the "we") might take the >>>> topic on and suggest ways which the IETF might do the work. >>>=20 >>> yep, thanks for the clarification. I actually meant "we" in the broad >>> sense of "the community of people who care about making communications >>> on the web more secure", which includes groups you didn't even mention >>> above, like web site designers, systems administrators, etc. >>>=20 >>> It's still on-topic here (despite the broad scope implied above) becaus= e >>> the TLS WG does have a role to play, by considering the merits of >>> proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as >>> well as considering alternatives that deal with this particular use cas= e. >>>=20 >>>>> option (A) is seriously hard, maybe impossible given the state of the >>>>> web. option (B) is terrible. >>>>=20 >>>> Exactly right, for any value of "we". >>>=20 >>> :( >>>=20 >>> --dkg >>>=20 >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >>=20 >>=20 >> -- >> email: rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>=20 >> _______________________________________________ >>=20 >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >>=20 >> _________________________________________________________ >> Michael Sweet, Senior Printing System Engineer, PWG Chair >>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 >=20 >=20 > --=20 > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Fri Mar 21 09:44:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05D11A0794 for ; Fri, 21 Mar 2014 09:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fVNknlvATCUU for ; Fri, 21 Mar 2014 09:44:04 -0700 (PDT) Received: from cheviot22.ncl.ac.uk (cheviot22.ncl.ac.uk [128.240.234.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3DABE1A09EA for ; Fri, 21 Mar 2014 09:44:03 -0700 (PDT) Received: from exhubvm03.ncl.ac.uk ([128.240.234.7] helo=EXHUBVM03.campus.ncl.ac.uk) by cheviot22.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1WR2Xx-0000cF-F2; Fri, 21 Mar 2014 16:43:53 +0000 Received: from EXMBCT02.campus.ncl.ac.uk ([fe80::5031:551d:4014:8606]) by EXHUBVM03.campus.ncl.ac.uk ([fe80::517e:5471:8227:7937%10]) with mapi id 14.03.0158.001; Fri, 21 Mar 2014 16:43:52 +0000 From: Feng Hao To: "Paterson, Kenny" Thread-Topic: [TLS] bootstrapping of constrained devices Thread-Index: AQHPRRjcZOSwvL63jEOuVHXP1gf5KZrrr/cAgAAEIYCAAAXY0A== Date: Fri, 21 Mar 2014 16:43:52 +0000 Message-ID: References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <532B9B65.4030708@gmail.com> <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com> <532C5867.2050704@gridmerge.com>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xWSzrB9589PkaSbRxGSB1OQW8Vk Cc: "tls@ietf.org" Subject: Re: [TLS] bootstrapping of constrained devices X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2014 16:44:06 -0000 Hi Kenny, >As far as I am aware, there's no complete formal security analysis of J-PA= KE. >There are claims in the original paper about the security conferred by the= use >of ZK proofs, and some informal security analysis (stated as theorems and >proofs), but, as far as I know, there's no security proof using a recognis= ed >PAKE security model. I responded to a similar comment on the lightbluetouchpaper blog about 6 ye= ars ago: http://www.lightbluetouchpaper.org/2008/05/29/j-pake/ (See Comment 29) My views are basically unchanged. Meanwhile, in the past 6 years, I've been= trying to search for answers of obvious questions: 1) what exact PAKE secu= rity model is the "right" model; 2) which exact PAKE protocol has been prov= ed secure under that model and how is that protocol implemented and used in= real life. I must admit I haven't found my answers.=20 Best regards, Feng From nobody Fri Mar 21 10:55:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508A31A03BF for ; Fri, 21 Mar 2014 10:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUUuzG8TQFdi for ; Fri, 21 Mar 2014 10:55:14 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9AC1A09FB for ; Fri, 21 Mar 2014 10:55:13 -0700 (PDT) Received: from mail118-co9-R.bigfish.com (10.236.132.229) by CO9EHSOBE005.bigfish.com (10.236.130.68) with Microsoft SMTP Server id 14.1.225.22; Fri, 21 Mar 2014 17:55:04 +0000 Received: from mail118-co9 (localhost [127.0.0.1]) by mail118-co9-R.bigfish.com (Postfix) with ESMTP id 4EB6FCC01D2 for ; Fri, 21 Mar 2014 17:55:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.5; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0310HT002.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: PS-2(zz98dI1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h17326ah8275dh1de097h186068hz2fh109h2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2052h20b3h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh1155h) Received-SPF: pass (mail118-co9: domain of rhul.ac.uk designates 157.56.248.5 as permitted sender) client-ip=157.56.248.5; envelope-from=Kenny.Paterson@rhul.ac.uk; helo=AMSPRD0310HT002.eurprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019001)(6009001)(428001)(24454002)(199002)(189002)(51704005)(83072002)(92726001)(85852003)(56816005)(90146001)(81542001)(92566001)(69226001)(15975445006)(81342001)(81686001)(82746002)(95666003)(47446002)(74482001)(87936001)(31966008)(74662001)(83322001)(74502001)(19580395003)(81816001)(33656001)(80976001)(2656002)(19580405001)(85306002)(65816001)(66066001)(20776003)(77982001)(53806001)(59766001)(80022001)(79102001)(76482001)(87266001)(83716003)(47736001)(49866001)(36756003)(47976001)(50986001)(4396001)(15202345003)(54316002)(56776001)(63696002)(94946001)(76786001)(54356001)(76796001)(94316002)(74876001)(97186001)(46102001)(93136001)(74706001)(95416001)(86362001)(93516002)(74366001)(51856001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB381; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:FEE0F11C.843A9702.31F5513B.45E9D060.202F1; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail118-co9 (localhost.localdomain [127.0.0.1]) by mail118-co9 (MessageSwitch) id 1395424502428170_16020; Fri, 21 Mar 2014 17:55:02 +0000 (UTC) Received: from CO9EHSMHS002.bigfish.com (unknown [10.236.132.225]) by mail118-co9.bigfish.com (Postfix) with ESMTP id 64060C40112; Fri, 21 Mar 2014 17:55:02 +0000 (UTC) Received: from AMSPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.5) by CO9EHSMHS002.bigfish.com (10.236.130.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 21 Mar 2014 17:55:01 +0000 Received: from DBXPR03MB381.eurprd03.prod.outlook.com (10.141.10.11) by AMSPRD0310HT002.eurprd03.prod.outlook.com (10.255.40.37) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 21 Mar 2014 17:54:47 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB381.eurprd03.prod.outlook.com (10.141.10.11) with Microsoft SMTP Server (TLS) id 15.0.898.11; Fri, 21 Mar 2014 17:54:46 +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.0898.005; Fri, 21 Mar 2014 17:54:46 +0000 From: "Paterson, Kenny" To: Feng Hao Thread-Topic: [TLS] bootstrapping of constrained devices Thread-Index: AQHPRRjdGRG2NbhO+U2QyRiSBBsmfJrrr/cAgAAEITCAAAsxAIAAE88d Date: Fri, 21 Mar 2014 17:54:45 +0000 Message-ID: <3AD3276A-8CEB-448C-867F-2BF7962149DE@rhul.ac.uk> References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <532B9B65.4030708@gmail.com> <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com> <532C5867.2050704@gridmerge.com>, , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.42.226.146] x-forefront-prvs: 0157DEB61B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.248.5$newcastle.ac.uk%23205%4%rhul.ac.uk%False%False%0$ X-OriginatorOrg: rhul.ac.uk X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%NEWCASTLE.AC.UK$RO%1$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KYx-8fJKucw4RlLvlwXbx14ifD8 Cc: "tls@ietf.org" Subject: Re: [TLS] bootstrapping of constrained devices X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2014 17:55:20 -0000 > On 21 Mar 2014, at 16:44, "Feng Hao" wrote: >=20 > Hi Kenny, >=20 >> As far as I am aware, there's no complete formal security analysis of J-= PAKE. >> There are claims in the original paper about the security conferred by t= he use >> of ZK proofs, and some informal security analysis (stated as theorems an= d >> proofs), but, as far as I know, there's no security proof using a recogn= ised >> PAKE security model. >=20 > I responded to a similar comment on the lightbluetouchpaper blog about 6 = years ago: >=20 The comment from Jon Katz from 6 years ago is not really that similar to mi= ne now, but I agree with him when he describes your security analysis as be= ing hand waving. > http://www.lightbluetouchpaper.org/2008/05/29/j-pake/ (See Comment 29) >=20 > My views are basically unchanged. That's a shame. I'd have hoped you'd have learned how to use PAKE models an= d formal security proofs in the intervening period.=20 > Meanwhile, in the past 6 years, I've been trying to search for answers of= obvious questions: 1) what exact PAKE security model is the "right" model;= 2) which exact PAKE protocol has been proved secure under that model and h= ow is that protocol implemented and used in real life. Very good. Models do evolve, and the first model is not always the "right" = one. Still, the provision of some analysis in one of the several by now qui= te standard models would not be an unreasonable expectation if you are seri= ously promoting J-PAKE over the alternatives.=20 > I must admit I haven't found my answers.=20 Indeed. But that should not stop you (or anyone else, but it's really on yo= u) from choosing one of the existing models and giving a proof for your pro= tocol. Cheers Kenny > Best regards, > Feng >=20 >=20 From nobody Fri Mar 21 13:25:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982D51A09F5 for ; Fri, 21 Mar 2014 13:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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, RCVD_IN_SORBS_WEB=0.77, 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 5_mFp2txsnp0 for ; Fri, 21 Mar 2014 13:24:54 -0700 (PDT) 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 2F13B1A08FA for ; Fri, 21 Mar 2014 13:24:54 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id d17so2223338eek.29 for ; Fri, 21 Mar 2014 13:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=csKKfB3Y4TaL4K3xqEJMWwe3cD3wEiquneppjV23fhA=; b=VAcg3ms65S73/dGlnc6pvjABs5sArFaPpMVU3+j0JQN3WARYBcmHPiRsQnZV+Cc4fE yofQhtlxLsraKp4PRGs/PMuzKWhZMrIO+1x4qKYkRCwClOcM8h1kCwAazWP1q9J8C6f1 J/ObMxXx6SCY8cD6hdFb6CP65qCZ87WqxvXsZMkvKThuNNqZmzEt0mI9r2qk6/aCpE/8 FbfSbVsp4DAY+zZ8qPpdz8UJYF5qt1R0fzyCDFU5yfxtDGxVw8DuKzoW/zTbI8KJCHrS qwZReSChPDIPZQbPw8/GZyALT1S0WC50ZgJhzAG0x9U87fL/Dfue9nloObxD0UKQV1uC 1Rbw== X-Received: by 10.15.73.134 with SMTP id h6mr31614473eey.3.1395433484369; Fri, 21 Mar 2014 13:24:44 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-179-48-141.red.bezeqint.net. [79.179.48.141]) by mx.google.com with ESMTPSA id bc51sm13944046eeb.22.2014.03.21.13.24.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 13:24:43 -0700 (PDT) Message-ID: <532CA00A.6070407@gmail.com> Date: Fri, 21 Mar 2014 22:24:42 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Yoav Nir , Paul Hoffman References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0rJSaZyPYJNebZQ_qh_AAksOCDg Cc: "tls@ietf.org" Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2014 20:24:56 -0000 > Huh. I was about to reply “you, me, Andy, and what army?” > > Seriously, we can’t establish a new norm in any forum that does not include web designers and UX people. Somewhere there are people who design the UX for people browsing Facebook, Gmail, my bank, Amazon and some web store selling dog food over the Internet. They get to decide what technology goes into the web site, and unfortunately none of them attend the meetings of any of the groups you mentioned. In fact, they don’t follow any IETF group, so we can’t even invite them all to a BoF. > > Given that, I don’t think any value of “we” that belongs to the IETF can establish any norms. I wish this was different. > > Yoav > There is a (small) discipline of "security usability". For example, see [1]. Some things that we do have a lot to do with usability, and I think it's time we engaged with that community. "We" here is the SAAG community. This applies to PAKE, browser "padlocks" and phishing. I think this also applies that which shall remain unnamed, but some people call OE, and some other people hate them for that. Thanks, Yaron [1] https://cups.cs.cmu.edu/soups/2014/ From nobody Fri Mar 21 13:39:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793281A0A1B for ; Fri, 21 Mar 2014 13:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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, RCVD_IN_SORBS_WEB=0.77, 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 90HQW-328nlA for ; Fri, 21 Mar 2014 13:39:37 -0700 (PDT) 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 2E8231A0A18 for ; Fri, 21 Mar 2014 13:39:37 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id e49so2221648eek.39 for ; Fri, 21 Mar 2014 13:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yPXNCGvCoCtl+NaZqYcCwbTIndXuONRZyiBeoLfEv8I=; b=Q7MTJtkZXfBC3RAGOe6AmPctQzMAavCQl82QJtnwGCwbdjCWoC9NfXY5Lf8t3r1KA3 ucX+vVLLDK2uzJgip55+XeTylFdcKCLaTEbKAgU1M5DpalGBQKCm9zVlrVzKO9urYuDv CbEo29fQ3RT6qPS3HCi/1oXP8EmGw3ZCsMg128jq9NpFOAQ/dvq2YUbfoqkRHHWxwNqS Y9dyqw2SxfOt/LvM3AG4X9xQbxXsbLCyrfHpq6ZwwfDQ+OzEvUtQ66P1ZRgfYeUaWU3F T1W+jGnImAuFW75AH6T4XwiECZUooIbYsWXQNe0pNYzKtk2YODk+MhHvHW7+TkMYbLQj Ns7g== X-Received: by 10.15.31.137 with SMTP id y9mr49897191eeu.12.1395434367348; Fri, 21 Mar 2014 13:39:27 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-179-48-141.red.bezeqint.net. [79.179.48.141]) by mx.google.com with ESMTPSA id cb5sm14024592eeb.18.2014.03.21.13.39.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 13:39:26 -0700 (PDT) Message-ID: <532CA37C.8030409@gmail.com> Date: Fri, 21 Mar 2014 22:39:24 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Andy Lutomirski , ryan-ietftls@sleevi.com References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8ZN_uvO24y-9dEezFStVTJl5SQA Cc: "tls@ietf.org" Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2014 20:39:38 -0000 > > Even for IMAP, using PAKE, augmented or balanced, would give a > significant amount of protection against MITMs who have compromised a > CA. Since compromising a CA seems to be a popular thing to do these > days, resisting these attacks at the protocol level would add > considerable value. > > --Andy > IMAP/SMTP is a great example where PAKE could add significant security: CA compromise is arguably rare, but coffee-shop captive portals that hijack IMAP/SMTP and present their own certificate are quite common. The user gets a message from their mail client asking if they will accept this certificate, and you can guess what they'll choose... Next thing you know, the password is sent in the clear to the server. Thanks, Yaron From nobody Mon Mar 24 04:33:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03981A01D3 for ; Mon, 24 Mar 2014 04:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 YbHKYNqJgBxQ for ; Mon, 24 Mar 2014 04:33:33 -0700 (PDT) Received: from cheviot22.ncl.ac.uk (cheviot22.ncl.ac.uk [128.240.234.22]) by ietfa.amsl.com (Postfix) with ESMTP id BE5A11A01CD for ; Mon, 24 Mar 2014 04:33:33 -0700 (PDT) Received: from exhubvm03.ncl.ac.uk ([128.240.234.7] helo=EXHUBVM03.campus.ncl.ac.uk) by cheviot22.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1WS38F-0000qT-FF; Mon, 24 Mar 2014 11:33:31 +0000 Received: from EXMBCT02.campus.ncl.ac.uk ([fe80::5031:551d:4014:8606]) by EXHUBVM03.campus.ncl.ac.uk ([fe80::517e:5471:8227:7937%10]) with mapi id 14.03.0158.001; Mon, 24 Mar 2014 11:33:05 +0000 From: Feng Hao To: "'Paterson, Kenny'" Thread-Topic: [TLS] bootstrapping of constrained devices Thread-Index: AQHPRRjcZOSwvL63jEOuVHXP1gf5KZrrr/cAgAAEIYCAAAXY0IAAGSeAgARDN3A= Date: Mon, 24 Mar 2014 11:33:04 +0000 Message-ID: References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <532B9B65.4030708@gmail.com> <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com> <532C5867.2050704@gridmerge.com>, , <3AD3276A-8CEB-448C-867F-2BF7962149DE@rhul.ac.uk> In-Reply-To: <3AD3276A-8CEB-448C-867F-2BF7962149DE@rhul.ac.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Xc3gDX_gShnsUmo-Wn6QvpjcuqQ Cc: "tls@ietf.org" Subject: Re: [TLS] bootstrapping of constrained devices X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Mar 2014 11:33:35 -0000 Hi Kenny, Thanks for your advice and expert comments. >That's a shame. I'd have hoped you'd have learned how to use PAKE models >and formal security proofs in the intervening period. I've learned that the formal model analysis (or "provable security") is tri= ckier than what I hoped to see. Maybe only time can tell if adding layers o= f formalism to the security proofs is really the right way to go.=20 >Indeed. But that should not stop you (or anyone else, but it's really on y= ou) >from choosing one of the existing models and giving a proof for your proto= col. Yes, I'm not giving up on it : ) Best regards, Feng From nobody Wed Mar 26 11:42:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8351A0386 for ; Wed, 26 Mar 2014 11:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 tE_3fU3H3PeI for ; Wed, 26 Mar 2014 11:42:54 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0B71A0172 for ; Wed, 26 Mar 2014 11:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=395; q=dns/txt; s=iport; t=1395859372; x=1397068972; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=cuR+hn7qv6hT6q5O1lKELPlzG7QOg5UhHNRJbYiWgoU=; b=hOrLFKWnT4zWxpdCgwW8EBoJhfMFVIrz74e2PSD8o7z2Q+UwjcxIjHqg HSJo9JCQLyq1Gahm4It0Zz49ttecLHa33UsGxbVe3GR4m9D2FlFXP6mpf NmIyHMMOh9TBd3k43dyFV9OZQhHTrTQvofkW3IpYOL9nugZOKVnRDYsXS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsFAEQfM1OtJXHB/2dsb2JhbABZgwaBEsQSFnSCLDpRAT5CJwSIDJ8ZsWwXkhyBFASYTZIzgy6CKw X-IronPort-AV: E=Sophos;i="4.97,737,1389744000"; d="scan'208";a="30599127" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-2.cisco.com with ESMTP; 26 Mar 2014 18:42:52 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2QIgqEI017745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Mar 2014 18:42:52 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.247]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Wed, 26 Mar 2014 13:42:52 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Confirmation of Consensus on Removing Compression from TLS 1.3 Thread-Index: AQHPSSMxZ0z0INsV8EeHhSnGu4GmzA== Date: Wed, 26 Mar 2014 18:42:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.91] Content-Type: text/plain; charset="us-ascii" Content-ID: <396A07315D02E24E9DA53B8962C5583C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xhMLf8j4pq8W_ZGXUUU1G_m6r1c Subject: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 18:42:55 -0000 The use of compression within TLS has resulted in vulnerabilities that can = be exploited to disclose TLS encrypted application data. The consensus in= the room at IETF-89 was to remove compression from TLS 1.3 to remove this = attack vector. If you have concerns about this decision please respond on = the TLS list by April 11, 2014. Thanks, Joe [Speaking for the TLS chairs]= From nobody Wed Mar 26 11:43:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF08D1A0392 for ; Wed, 26 Mar 2014 11:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 vZVSoOxFyAvD for ; Wed, 26 Mar 2014 11:43:09 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 32E611A038B for ; Wed, 26 Mar 2014 11:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=759; q=dns/txt; s=iport; t=1395859388; x=1397068988; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=DR8MT6rroQOBauPG1uRoRmJZ5pvIgmWVYNXZ53+MT+I=; b=arJUMqSiC9THl+axGKdvTTgMzQnV4pnzGI3OoquEus57E/meYyObmwj5 6ZDmJULCnXffgS62L33F+gh+hxuR+qdZjZzxgOWpJkn/Z3D5xlMpJd9nr Y6yWk3XoE2egiEcFxtxQLB8577VCVXRNoGKVL+pze/NPB8ThKJkThcvg6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsFABEfM1OtJXG9/2dsb2JhbABZgwaBEsQSFnSCLDpRAT5CJwSIDJ8ZsWwXkhyBFASYTZIzgy6CKw X-IronPort-AV: E=Sophos;i="4.97,737,1389744000"; d="scan'208";a="313111695" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 26 Mar 2014 18:43:07 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2QIh7xF005881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Mar 2014 18:43:07 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.247]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Wed, 26 Mar 2014 13:43:07 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Confirming Consensus on supporting only AEAD ciphers Thread-Index: AQHPSSM6qiIeFUDRHUase0LCUT6SLg== Date: Wed, 26 Mar 2014 18:43:07 +0000 Message-ID: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.91] Content-Type: text/plain; charset="us-ascii" Content-ID: <05669CBBCB757E4AAD5FD12C16C133CF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uOg9coqQJrtnuhaHO2ne96nlX84 Subject: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 18:43:11 -0000 TLS has supported a number of different cipher types for protecting the rec= ord layer. In TLS 1.3 these include Stream Cipher, CBC Block Cipher and A= EAD Cipher. The construction of the CBC mode within TLS has been shown to = be flawed and stream ciphers are not generally applicable to DTLS. Using a = single mechanism for cryptographic transforms would make security analysis = easier. AEAD ciphers can be constructed from stream ciphers and block cip= hers and are defined as protocol independent transforms. The consensus in = the room at IETF-89 was to only support AEAD ciphers in TLS 1.3. If you hav= e concerns about this decision please respond on the TLS list by April 11, = 2014. Thanks, Joe [Speaking for the TLS chairs]= From nobody Wed Mar 26 11:43:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF93E1A03A0 for ; Wed, 26 Mar 2014 11:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 vHKhnKPgt9-G for ; Wed, 26 Mar 2014 11:43:26 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 790311A038B for ; Wed, 26 Mar 2014 11:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=704; q=dns/txt; s=iport; t=1395859400; x=1397069000; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=cBqW6H3BDwbKcz1uWGhvIORKR3xe8h6n8QOZZ7OLcFQ=; b=j2YsuFKOBKd2np+0jY6S3PFn2740gb+lYyaMgL9pTcJtTLrr1gvfMGec gK7kQLDIqSxdBrRiHA7ya7RheCfMfGbglqiD+iqvtnomygXo0HSJXM4sT nOHpUQdngsJoiZbzcIGYNNvqobJKWGW+b2we8MeMRZ2QPSZjImrCCTuXB w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsFAEQfM1OtJXG9/2dsb2JhbABZgwaBEsQSFnSCLDpRAT5CJwSIDJ8ZsWwXjg6EDoEUBJhNkjODLoIr X-IronPort-AV: E=Sophos;i="4.97,737,1389744000"; d="scan'208";a="30598729" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-1.cisco.com with ESMTP; 26 Mar 2014 18:43:19 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2QIhJF4006072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Mar 2014 18:43:19 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.247]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Wed, 26 Mar 2014 13:43:19 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Confirming Consensus on removing RSA key Transport from TLS 1.3 Thread-Index: AQHPSSNBHMLaOP6B/EejoHSZ5uWtRg== Date: Wed, 26 Mar 2014 18:43:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.91] Content-Type: text/plain; charset="us-ascii" Content-ID: <3303029BC3BA0B41926C1DFE594B5C00@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/f7WVUwsTe5ACGhIPxXe3BSlvI3M Subject: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 18:43:28 -0000 TLS has had cipher suites based on RSA key transport (aka "static RSA", TLS= _RSA_WITH_*) since the days of SSL 2.0. These cipher suites have several = drawbacks including lack of PFS, pre-master secret contributed only by the = client, and the general weakening of RSA over time. It would make the secu= rity analysis simpler to remove this option from TLS 1.3. RSA certificates= would still be allowed, but the key establishment would be via DHE or ECDH= E. The consensus in the room at IETF-89 was to remove RSA key transport fr= om TLS 1.3. If you have concerns about this decision please respond on the= TLS list by April 11, 2014. Thanks, Joe [Speaking for the TLS chairs]= From nobody Wed Mar 26 12:08:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692891A0354 for ; Wed, 26 Mar 2014 12:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCHg6odGPfXA for ; Wed, 26 Mar 2014 12:08:41 -0700 (PDT) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 730751A02D7 for ; Wed, 26 Mar 2014 12:08:41 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c13so2038425eek.10 for ; Wed, 26 Mar 2014 12:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=nX4Wh/xIcSMk1X7cwgNYAF6CoZAP68Ko3+wxRuJXF9g=; b=WFLjawEXCnc1UEHwYthCvDI3cEfSsXsS22JY608Qe7COgJRgVGNArYHF0bi7HccP9X Y0D4ZtvlS77uaJQ9qEjunsntwwGSICJ7HjpAAsmcl/i1zPE+jCKga3e+f3P+cAlYbiEw XumibKj9nFNv7hRrJevpKccmG/mfVJVxhcGT7bwVhWaqVRSjgC3zhdT+Z5SPkDfh7d11 8yYW94vM7JIBFfG7gdXcVyYmHp7DAEwpH6QUZRTxnRorxBDKNFliajrTTadldnVz6PHI cYbYdbp9xJCQyWl2sYGMTg0b0B37UzSOGwdWPNhCDOi0LbDrFd0ZsjD2tJGAIEznLgkU SJhQ== X-Received: by 10.15.111.206 with SMTP id cj54mr76332285eeb.8.1395860919537; Wed, 26 Mar 2014 12:08:39 -0700 (PDT) Received: from [192.168.51.244] (217.64.249.186.mactelecom.net. [217.64.249.186]) by mx.google.com with ESMTPSA id 48sm48961036eee.2.2014.03.26.12.08.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Mar 2014 12:08:38 -0700 (PDT) Message-ID: <533325B5.7090705@gmail.com> Date: Wed, 26 Mar 2014 15:08:37 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" , "" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dedRfoOf3MCrxdf7oHx-v2N5dkc Subject: [TLS] On axing DHE (was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 19:08:43 -0000 Hi Joe: If one has concerns re "the general weakening of RSA over time", what about putting DHE (or, if one has more modest aspirations: DHE with MODp groups with short exponents) on the chopping block as well? Best regards, Rene On 3/26/2014 2:43 PM, Joseph Salowey (jsalowey) wrote: > TLS has had cipher suites based on RSA key transport (aka "static RSA", TLS_RSA_WITH_*) since the days of SSL 2.0. These cipher suites have several drawbacks including lack of PFS, pre-master secret contributed only by the client, and the general weakening of RSA over time. It would make the security analysis simpler to remove this option from TLS 1.3. RSA certificates would still be allowed, but the key establishment would be via DHE or ECDHE. The consensus in the room at IETF-89 was to remove RSA key transport from TLS 1.3. If you have concerns about this decision please respond on the TLS list by April 11, 2014. > > Thanks, > > Joe > [Speaking for the TLS chairs] > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Wed Mar 26 12:31:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131CC1A03C1 for ; Wed, 26 Mar 2014 12:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nl_08mxdsJ-z for ; Wed, 26 Mar 2014 12:31:01 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9BD1A03B9 for ; Wed, 26 Mar 2014 12:31:01 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id r20so5045914wiv.9 for ; Wed, 26 Mar 2014 12:30:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ysulZJ3AxEl4jLCGyZHvFpziOduyb1vQvhFouaLMgGM=; b=Kg3Z2VLxLcVKRH5QopJKkwNa7e1BJn/vqJ5cJOf0rgkJuug+WKaO6UG3x2aGnVcE73 a5ENf7AiqDXwcEbuz9HXqXYp+8MJ7cFCZZVys4ifKedKTtYZbl5a45EosNtXQBQtVlB2 rJ8Q5Eviq3FrmdFcuCMjQUfIDuE23/ktJkmf0iQ9ulkNlQUYMUCwktJoXyUvKiehfBcm ePIL/anOZaLDSt9M0XApl5pQUlj3DRQinPOn4TLu32JvVRXB/jsXqU6iOILRlNvZwk/E NkrWSU2eT1dboLYo/m3Mp0VSvz82sOcuJZK51Wp+NLoHZyfxnCeODFnJl4uo5KXXcwod Yxlg== X-Gm-Message-State: ALoCoQnWjb7o6p6A+woTN2KTiUW0/Ia6WL4V+g6wWTd4cd8kcOy/kijUYJ99RsUNQPugkGx3lAal MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr34631715wib.39.1395862259265; Wed, 26 Mar 2014 12:30:59 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Wed, 26 Mar 2014 12:30:59 -0700 (PDT) X-Originating-IP: [184.23.29.222] In-Reply-To: References: Date: Wed, 26 Mar 2014 12:30:59 -0700 Message-ID: From: Trevor Perrin To: "Joseph Salowey (jsalowey)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Q3gjNn5PUScuC1zn6rG6IVQRedg Cc: "" Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 19:31:03 -0000 Hi Joe, Could you explain what the process for TLS 1.3 is? It seems like you want the group to start making lots of small, specific decisions. I'm not convinced that's the best way to design a complex protocol with lots of inter-related pieces. I was hoping we'd have some discussion on the TLS 1.3 process, now that the charter is approved. Is that not going to happen? Trevor On Wed, Mar 26, 2014 at 11:43 AM, Joseph Salowey (jsalowey) wrote: > TLS has had cipher suites based on RSA key transport (aka "static RSA", T= LS_RSA_WITH_*) since the days of SSL 2.0. These cipher suites have severa= l drawbacks including lack of PFS, pre-master secret contributed only by th= e client, and the general weakening of RSA over time. It would make the se= curity analysis simpler to remove this option from TLS 1.3. RSA certificat= es would still be allowed, but the key establishment would be via DHE or EC= DHE. The consensus in the room at IETF-89 was to remove RSA key transport = from TLS 1.3. If you have concerns about this decision please respond on t= he TLS list by April 11, 2014. > > Thanks, > > Joe > [Speaking for the TLS chairs] > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Mar 26 12:40:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C821A01F7 for ; Wed, 26 Mar 2014 12:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiT1mAQTPg8t for ; Wed, 26 Mar 2014 12:40:49 -0700 (PDT) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF791A01AB for ; Wed, 26 Mar 2014 12:40:49 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id b57so2030702eek.35 for ; Wed, 26 Mar 2014 12:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=TKxBJ4ul6ZGoJPSQropV6xkOhRt1Okz4/oKX4/NyfWI=; b=zhF9TRtkTPhMWNHzl5+tyxfQujVfqzbz6k2UdDKBVUMiVgjr8D1oMWvtdYzzYTeLOo wImvGjzlyyyRzTbj9i+DQoIWBf0v95zbpNYG8ofTdghLZsCgltWKp7CG42OguRKiZu59 Ojp1+XHNl276xK+wXnx3erHO1HUsziVbul1xXXzGn3mcWtcSegIC3PqpNcTpFDJzHwa0 +evT7Nd9BjLW+xhypstOZYjOvOncYomYAWiHSS0DHqlCed9uDld+2GE7cZ0IS7yrJ7/q 6s096Dwk4tH58UyLClzVxRthWvmsdX11lLAC77EgldBOB8BfP67G8VGuaoJg4IwUTFnD T/uA== X-Received: by 10.14.241.139 with SMTP id g11mr13912632eer.49.1395862847168; Wed, 26 Mar 2014 12:40:47 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-182-10-128.red.bezeqint.net. [79.182.10.128]) by mx.google.com with ESMTPSA id w1sm35013797eel.16.2014.03.26.12.40.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Mar 2014 12:40:46 -0700 (PDT) Message-ID: <53332D3D.5020908@gmail.com> Date: Wed, 26 Mar 2014 21:40:45 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" , "" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BgnMbf_iDqMs92Q2etXqpQxWIpo Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Mar 2014 19:40:54 -0000 I think this would be a mistake. I would recommend instead to say that compression SHOULD be disabled by default. But leave the option in the protocol for applications that need compression and are able to mitigate the vulnerability. This does NOT include normal Web traffic. The reason is that we have compression at the HTTP layer too, it is widely used, and is subject to similar vulnerabilities when run over TLS. AFAIK, no-one is proposing to ban HTTP compression [1]. So we're just moving the problem to a different protocol layer, one that may be less security conscious. And in general, an encrypted transport should provide compression as one of its services. Architecturally this is the right level, which is why it was put there in the first place. Thanks, Yaron [1] http://http2.github.io/http2-spec/index.html#rfc.section.10.6 On 03/26/2014 08:42 PM, Joseph Salowey (jsalowey) wrote: > The use of compression within TLS has resulted in vulnerabilities that can be exploited to disclose TLS encrypted application data. The consensus in the room at IETF-89 was to remove compression from TLS 1.3 to remove this attack vector. If you have concerns about this decision please respond on the TLS list by April 11, 2014. > > Thanks, > > Joe > [Speaking for the TLS chairs] > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Mar 26 12:57:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D51D1A03CC for ; Wed, 26 Mar 2014 12:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jds92ZQU8wWk for ; Wed, 26 Mar 2014 12:57:17 -0700 (PDT) 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 08AE11A01E9 for ; Wed, 26 Mar 2014 12:57:16 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so1623071wgg.13 for ; Wed, 26 Mar 2014 12:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xZPxXK/NGG3nm9asSrrcu0UwVFKcxpGvosxnxem9Q1A=; b=vBYxe08wXe+KLgGeN5exXl7ZeZ2woymMrej+erTa1hZNwE/Vs3H5X+cy+JMOXtGKpn BAgETvTip3k6mtZT/WrSvk+YjaTDJEVgKxeJXM6OOKvlYlEA2mIBdYIPsomiGgtCNiUJ F9FPSIZlEOPOgRgHEdJ8TpthEXzD03XDwUX9vdPVJMldL0jdmWQsPW3gvxKRAnUXcFA+ yVxAdahb0qHLoWQySvm8wwk9gilx5haQcR5Z2G3d6ATNs1MSTpxQaSD+QfEBNr1hMZgu peAf8Ubgp4OlAtEhTJ0p4F+kpdOgNqo+RK7mpOVfGbMNmlVhhBR1mKGKNAbWLjECfWks 54VQ== MIME-Version: 1.0 X-Received: by 10.180.221.68 with SMTP id qc4mr31795694wic.30.1395863834946; Wed, 26 Mar 2014 12:57:14 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Wed, 26 Mar 2014 12:57:14 -0700 (PDT) In-Reply-To: <53332D3D.5020908@gmail.com> References: <53332D3D.5020908@gmail.com> Date: Wed, 26 Mar 2014 12:57:14 -0700 Message-ID: From: Martin Thomson To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UjHNYNyuysDlbBb9WmM7zXE_pdE Cc: "" Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Mar 2014 19:57:18 -0000 On 26 March 2014 12:40, Yaron Sheffer wrote: > The reason is that we have compression at the HTTP layer too, it is widely > used, and is subject to similar vulnerabilities when run over TLS. AFAIK, > no-one is proposing to ban HTTP compression [1]. So we're just moving the > problem to a different protocol layer, one that may be less security > conscious. I think that this is perhaps the wrong interpretation. I wouldn't want to assume that TLS has a monopoly on communications security. HTTPbis is acutely aware of the risks that compression comes with. Compression is critical to the performance of HTTP/2. HTTP/2 has mandated support for compression, despite the risks, because the performance gains are considered worth pursuing anyway. The general trend I've observed in these discussions is to move the decision to compress closer to the application. This means that the decision can be informed better by context. Generically applied compression is necessarily less aware of constraints on its use. For that reason, I support the decision here. Application protocols will be more aware of hazards. TLS will be easier to build without this baggage. From nobody Wed Mar 26 13:56:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113CB1A03CB for ; Wed, 26 Mar 2014 13:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHsKKumVA0D1 for ; Wed, 26 Mar 2014 13:56:25 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 512DE1A03C6 for ; Wed, 26 Mar 2014 13:56:25 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s2QKuI4p003225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Mar 2014 21:56:18 +0100 (MET) In-Reply-To: To: "Joseph Salowey (jsalowey)" Date: Wed, 26 Mar 2014 21:56:18 +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: <20140326205618.19F9A1AC7D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UiutrWMxylBQPycDkiGrcIx4WQw Cc: tls@ietf.org Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 20:56:28 -0000 Joseph Salowey (jsalowey) wrote: > > The use of compression within TLS has resulted in vulnerabilities > that can be exploited to disclose TLS encrypted application data. > The consensus in the room at IETF-89 was to remove compression from > TLS 1.3 to remove this attack vector. If you have concerns about > this decision please respond on the TLS list by April 11, 2014. This characterization about the use of compression in TLS is sufficiently misleading that it is wrong. First of all, the problem is nowhere specific to TLS, and affects compression anywhere within the software protocol stack. Besides, compression only aggravates the problem when either the entropy of all data within a TLS record is so extremely low, that the TLS record size difference will make the difference. As I previously noted on this list, the way it is specified, the TLS compression function could be used to provide a random padding of TLS records, so that all TLS records come out in equal size, essentially a form of anti-compression. And that could be applied to all existing cipher suites, including Stream ciphers and AEAD -- both of which do not allow any padding at all so far and therefor leak much more about the protected traffic than cipher suites that use the GenericBlockCipher PDU. The only situation where compression in general at the TLS-level aggravate the problem in any meaningful fashion is when either one or both of the endpoints do extraordinarily stupid things, like multiplexing attacker-supplied data with data that the attacker is not supposed to know into the same compression function (i.e. protect it with the very same TLS connection state rather than through seperate TLS connection states (i.e. with independent traffic protection keys), which is a clear an obvious fallacy, in clear abuse of the TLS protocol: http://tools.ietf.org/html/rfc5246#page-16 Any protocol designed for use over TLS must be carefully designed to deal with all possible attacks against it. As a practical matter, this means that the protocol designer must be aware of what security properties TLS does and does not provide and cannot safely rely on the latter. Our implementation does not implement support for compression so far, but if anyone wanted to have support for random padding in Stream and AEAD ciphers within TLS (v1.0-v1.2) I would really prefer to see that being done through an (anti-)compression scheme rather than changing all of the 2/3 Encryption PDUs seperately. For TLSv1.3, support for random (sized) padding could be added by appropriate definition of the respective PDUs and their processing, but that will reduce the code sharing further and further. -Martin From nobody Wed Mar 26 14:11:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49971A03D4 for ; Wed, 26 Mar 2014 14:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJJGIAv97weh for ; Wed, 26 Mar 2014 14:11:20 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5D15A1A03D2 for ; Wed, 26 Mar 2014 14:11:20 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hr14so3705843wib.4 for ; Wed, 26 Mar 2014 14:11:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=a2MjE7iSNCs17e7wDqSHjA36XvEiEJh8K8dPENGsjvk=; b=i3kHfc7QRHtgjIYdLbx9ZTfr6RNRgU+OZ89EkAV5OrJxN+9ZQK+KFASYevVabo11Rg DHCO3YHgn81kXu0kHY/KU2YH1c0JVEb9GfDCs3XflOB05QrRS9gm/UCOykBM1l2HIJ0O ZlWEWAPX94M5C+76GoxZnXmaUI7HoU8tDw6ZmTtX+r4Z0kb59q8cA8Ak0ABvtiCKEOLR j3J0vvhRQngs9xH/pwHc5rBay3JrJ+6zAQf3qQF6h84R5ha8NvolRP0XSNI0Y+vRAmgk 93BzWk21MOD3qhDCGTXArflpvmyee69jygAEqNswd75SsXuuKZEkTXCcqI8QRt8h9f+J 6brQ== X-Gm-Message-State: ALoCoQljHS1B1u1pJVjGRtSuU69X++jLO3o820QOfBuFWvCNdp9fWGLyy9c54WmHYDNMzhePwyoy X-Received: by 10.180.90.140 with SMTP id bw12mr29650wib.18.1395868278119; Wed, 26 Mar 2014 14:11:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 26 Mar 2014 14:10:38 -0700 (PDT) X-Originating-IP: [173.8.17.118] In-Reply-To: <20140326205618.19F9A1AC7D@ld9781.wdf.sap.corp> References: <20140326205618.19F9A1AC7D@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Wed, 26 Mar 2014 17:10:38 -0400 Message-ID: To: "mrex@sap.com" Content-Type: multipart/alternative; boundary=f46d043c811adefabe04f588e876 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8HcyMyDfMNLt8PWNY__hcJA5XGk Cc: "tls@ietf.org" Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Mar 2014 21:11:29 -0000 --f46d043c811adefabe04f588e876 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 26, 2014 at 4:56 PM, Martin Rex wrote: > Joseph Salowey (jsalowey) wrote: > > > > The use of compression within TLS has resulted in vulnerabilities > > that can be exploited to disclose TLS encrypted application data. > > The consensus in the room at IETF-89 was to remove compression from > > TLS 1.3 to remove this attack vector. If you have concerns about > > this decision please respond on the TLS list by April 11, 2014. > > This characterization about the use of compression in TLS is > sufficiently misleading that it is wrong. > > First of all, the problem is nowhere specific to TLS, and affects > compression anywhere within the software protocol stack. > > Besides, compression only aggravates the problem when either the entropy > of all data within a TLS record is so extremely low, that the TLS record > size difference will make the difference. > > As I previously noted on this list, the way it is specified, the TLS > compression function could be used to provide a random padding of TLS > records, so that all TLS records come out in equal size, essentially > a form of anti-compression. And that could be applied to all existing > cipher suites, including Stream ciphers and AEAD -- both of which > do not allow any padding at all so far and therefor leak much more > about the protected traffic than cipher suites that use the > GenericBlockCipher PDU. > > > The only situation where compression in general at the TLS-level > aggravate the problem in any meaningful fashion is when either one > or both of the endpoints do extraordinarily stupid things, like > multiplexing attacker-supplied data with data that the attacker is not > supposed to know into the same compression function (i.e. protect it > with the very same TLS connection state rather than through seperate > TLS connection states (i.e. with independent traffic protection keys), > which is a clear an obvious fallacy, in clear abuse of the TLS protocol: > Hmm... SSL/TLS was originally designed to protect Web traffic and this design of mixing attacker-supplied and sensitive information is a basic part of the Web, so I'm not sure I would really call it an "abuse" of TLS. In any case, it's a fairly common modality, so it seems like we need to provide TLS modes that are secure under this use case. This isn't to say that *all* TLS modes necessarily need to be so (though obviously it would be simpler that way) but if we don't supply a version of TLS that is safe for the Web, I don't think we've done our job. -Ekr --f46d043c811adefabe04f588e876 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 26, 2014 at 4:56 PM, Martin Rex <<= a href=3D"mailto:mrex@sap.com" target=3D"_blank">mrex@sap.com> wrote:
Joseph Salowey (jsalowey) wr= ote:
>
> The use of compression within TLS has resulted in vulnerabilities
> that can be exploited to disclose TLS encrypted application data.
> The consensus in the room at IETF-89 was to remove compression from > TLS 1.3 to remove this attack vector. =A0If you have concerns about > this decision please respond on the TLS list by April 11, 2014.

This characterization about the use of compression in TLS is
sufficiently misleading that it is wrong.

First of all, the problem is nowhere specific to TLS, and affects
compression anywhere within the software protocol stack.

Besides, compression only aggravates the problem when either the entropy of all data within a TLS record is so extremely low, that the TLS record size difference will make the difference.

As I previously noted on this list, the way it is specified, the TLS
compression function could be used to provide a random padding of TLS
records, so that all TLS records come out in equal size, essentially
a form of anti-compression. =A0And that could be applied to all existing cipher suites, including Stream ciphers and AEAD -- both of which
do not allow any padding at all so far and therefor leak much more
about the protected traffic than cipher suites that use the
GenericBlockCipher PDU.


The only situation where compression in general at the TLS-level
aggravate the problem in any meaningful fashion is when either one
or both of the endpoints do extraordinarily stupid things, like
multiplexing attacker-supplied data with data that the attacker is not
supposed to know into the same compression function (i.e. protect it
with the very same TLS connection state rather than through seperate
TLS connection states (i.e. with independent traffic protection keys),
which is a clear an obvious fallacy, in clear abuse of the TLS protocol:

Hmm... SSL/TLS was originally designed to= protect Web traffic and this
design of mixing attacker-supplied = and sensitive information is a basic
part of the Web, so I'm not sure I would really call it an "a= buse" of TLS.

In any case, it's a fairly = common modality, so it seems like we need
to provide TLS modes th= at are secure under this use case. This isn't
to say that *all* TLS modes necessarily need to be so (though obviousl= y
it would be simpler that way) but if we don't supply a vers= ion of TLS
that is safe for the Web, I don't think we've = done our job.

-Ekr



=
--f46d043c811adefabe04f588e876-- From nobody Wed Mar 26 14:12:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EBC1A03CE for ; Wed, 26 Mar 2014 14:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUkvjSoX1Tdv for ; Wed, 26 Mar 2014 14:12:23 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 947B91A0232 for ; Wed, 26 Mar 2014 14:12:23 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s2QLCJsU006002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Mar 2014 22:12:19 +0100 (MET) In-Reply-To: To: "Joseph Salowey (jsalowey)" Date: Wed, 26 Mar 2014 22:12:19 +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: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NSAbRP0_iT-itqrol_tjPgGR3w0 Cc: tls@ietf.org Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 21:12:26 -0000 Joseph Salowey (jsalowey) wrote: > > TLS has had cipher suites based on RSA key transport (aka "static RSA", > TLS_RSA_WITH_*) since the days of SSL 2.0. These cipher suites have > several drawbacks including lack of PFS, pre-master secret contributed > only by the client, and the general weakening of RSA over time. > It would make the security analysis simpler to remove this option from > TLS 1.3. RSA certificates would still be allowed, but the key > establishment would be via DHE or ECDHE. The consensus in the room > at IETF-89 was to remove RSA key transport from TLS 1.3. If you have > concerns about this decision please respond on the TLS list by > April 11, 2014. To me that looks like a pretty bogus statement. There really is nothing wrong with static RSA, and I can conceive a number of scenarios where (EC)DHE could make the situation much worse. DHE has the problem that it lacks a required set of parameters. Generating everything anew and having to verify all parameters on the client side for each and every handshake is prohibitively expensive, so a number of implementations seem to be using a static keypair for the server that is manually generated by an admin once, and never refreshed/ updated, making it appear better than static RSA, but de-facto much worse. Small devices that currently have poor entropy sources may be much better off with a static RSA keypair once generated by an admin on a machine with good entropy and then pushed onto the device rather then having to frequently generate new keys on such a device. If RSA was weak, _any_single_use_ of RSA would make you "vulnerable", not just the RSA encryption of the premaster secret, but in just the same fashion the RSA signature on the (EC)DHE parameter in the ServerKeyExchange handshake message. Or the signatures on the certificate chain, or the signatures on the OCSP responses or CRLs. And once you do the whole PKI glory (long and complex certificate chains and full revocation galore, then you may realize that RSA still has a significant performance advantage over the alternatives. -Martin From nobody Wed Mar 26 14:19:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1781A03D4 for ; Wed, 26 Mar 2014 14:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HemkrFwK1Uxc for ; Wed, 26 Mar 2014 14:19:49 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 475DC1A03C0 for ; Wed, 26 Mar 2014 14:19:49 -0700 (PDT) Received: from mail87-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.22; Wed, 26 Mar 2014 21:19:47 +0000 Received: from mail87-va3 (localhost [127.0.0.1]) by mail87-va3-R.bigfish.com (Postfix) with ESMTP id 4218D1C0094; Wed, 26 Mar 2014 21:19:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.5; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0310HT004.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(z579ehz98dI2bc7M1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hz31iz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2052h20b3h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh1155h) Received-SPF: pass (mail87-va3: domain of rhul.ac.uk designates 157.56.248.5 as permitted sender) client-ip=157.56.248.5; envelope-from=Kenny.Paterson@rhul.ac.uk; helo=AMSPRD0310HT004.eurprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(24454002)(199002)(51704005)(74876001)(15975445006)(76786001)(76796001)(83072002)(56816005)(85852003)(74706001)(74366001)(81686001)(90146001)(74502001)(82746002)(47736001)(47976001)(4396001)(15202345003)(81816001)(36756003)(50986001)(33656001)(83716003)(87266001)(98676001)(2656002)(87936001)(74662001)(31966008)(80976001)(74482001)(49866001)(47446002)(92566001)(93136001)(92726001)(81542001)(81342001)(93516002)(97186001)(63696002)(54356001)(65816001)(66066001)(56776001)(54316002)(51856001)(46102001)(85306002)(80022001)(59766001)(77982001)(86362001)(95416001)(79102001)(19580395003)(95666003)(76482001)(94946001)(53806001)(19580405001)(94316002)(97336001)(83322001)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB383; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:EC7FF1A5.9CFA91E1.BDE2107B.4E39D971.204FA; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail87-va3 (localhost.localdomain [127.0.0.1]) by mail87-va3 (MessageSwitch) id 1395868785808480_4255; Wed, 26 Mar 2014 21:19:45 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.249]) by mail87-va3.bigfish.com (Postfix) with ESMTP id B5CE2240062; Wed, 26 Mar 2014 21:19:45 +0000 (UTC) Received: from AMSPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.5) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 26 Mar 2014 21:19:41 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by AMSPRD0310HT004.eurprd03.prod.outlook.com (10.255.40.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Wed, 26 Mar 2014 21:19:40 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) with Microsoft SMTP Server (TLS) id 15.0.898.11; Wed, 26 Mar 2014 21:19:38 +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.0898.005; Wed, 26 Mar 2014 21:19:38 +0000 From: "Paterson, Kenny" To: "" Thread-Topic: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 Thread-Index: AQHPSSMxZ0z0INsV8EeHhSnGu4GmzJrz2WQAgAAGhTY= Date: Wed, 26 Mar 2014 21:19:37 +0000 Message-ID: <2E8232FA-CFDF-42AA-A405-0B080EFE0135@rhul.ac.uk> References: , <20140326205618.19F9A1AC7D@ld9781.wdf.sap.corp> In-Reply-To: <20140326205618.19F9A1AC7D@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: [80.42.218.130] x-forefront-prvs: 0162ACCC24 Content-Type: text/plain; charset="us-ascii" 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% Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NiVXxr3Z9gftvLFDy4yPGFE5ums Cc: "tls@ietf.org" Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Mar 2014 21:19:52 -0000 Comments inline=20 > On 26 Mar 2014, at 20:56, "Martin Rex" wrote: >=20 > Joseph Salowey (jsalowey) wrote: >>=20 >> The use of compression within TLS has resulted in vulnerabilities >> that can be exploited to disclose TLS encrypted application data. >> The consensus in the room at IETF-89 was to remove compression from >> TLS 1.3 to remove this attack vector. If you have concerns about >> this decision please respond on the TLS list by April 11, 2014. >=20 > This characterization about the use of compression in TLS is > sufficiently misleading that it is wrong. Really? I assume you know about CRIME?? >=20 > First of all, the problem is nowhere specific to TLS, and affects > compression anywhere within the software protocol stack. This much is true. But we can at least remove the problem at one layer, whe= re it's particularly easy to exploit.=20 >=20 > Besides, compression only aggravates the problem when either the entropy > of all data within a TLS record is so extremely low, that the TLS record > size difference will make the difference. But sometimes an attacker can arrange exactly this to be the case - as in C= RIME.=20 > As I previously noted on this list, the way it is specified, the TLS > compression function could be used to provide a random padding of TLS > records, so that all TLS records come out in equal size, essentially > a form of anti-compression. =20 What would you choose for that size? The max fragment size could end up bei= ng very wasteful in many application scenarios; the MAC overhead would be u= nacceptable in other use cases if the size was small.=20 > And that could be applied to all existing > cipher suites, including Stream ciphers and AEAD -- both of which > do not allow any padding at all so far and therefor leak much more > about the protected traffic than cipher suites that use the > GenericBlockCipher PDU.=20 CRIME can also be applied to CBC mode cipher suites, with some care.=20 > The only situation where compression in general at the TLS-level > aggravate the problem in any meaningful fashion is when either one > or both of the endpoints do extraordinarily stupid things, like > multiplexing attacker-supplied data with data that the attacker is not > supposed to know into the same compression function (i.e. protect it > with the very same TLS connection state rather than through seperate > TLS connection states (i.e. with independent traffic protection keys), > which is a clear an obvious fallacy, in clear abuse of the TLS protocol: >=20 >=20 > http://tools.ietf.org/html/rfc5246#page-16 >=20 > Any protocol designed for use over TLS must be carefully designed to > deal with all possible attacks against it. As a practical matter, > this means that the protocol designer must be aware of what security > properties TLS does and does not provide and cannot safely rely on > the latter. >=20 >=20 Again, the CRIME case is instructive. Merely having malicious JavaScript th= at can connect to a remote https site can lead to cookies being recovered. = There, you can't stop attacker supplied data (http GET requests) being inte= rleaved with sensitive data (secure cookies). I don't think i would charact= erise this as being "extraordinarily stupid".=20 >=20 > Our implementation does not implement support for compression so far, > but if anyone wanted to have support for random padding in Stream and > AEAD ciphers within TLS (v1.0-v1.2) I would really prefer to see that > being done through an (anti-)compression scheme rather than changing > all of the 2/3 Encryption PDUs seperately. >=20 > For TLSv1.3, support for random (sized) padding could be added by > appropriate definition of the respective PDUs and their processing, > but that will reduce the code sharing further and further. I believe that random amounts of padding plus compression can still be brok= en by CRIME-like attacks, using only slightly more sophisticated statistica= l methods.=20 Cheers Kenny >=20 >=20 > -Martin >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Wed Mar 26 15:02:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067F11A03CF for ; Wed, 26 Mar 2014 15:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsyHFQ60nmka for ; Wed, 26 Mar 2014 15:02:05 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 440021A0223 for ; Wed, 26 Mar 2014 15:02:05 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s2QM20dO014001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Mar 2014 23:02:00 +0100 (MET) In-Reply-To: <2E8232FA-CFDF-42AA-A405-0B080EFE0135@rhul.ac.uk> To: "Paterson, Kenny" Date: Wed, 26 Mar 2014 23:02:00 +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: <20140326220200.6A9781AC7D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/23GNcEc1MJN68wchDAqXrGHW5zQ Cc: "tls@ietf.org" Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 22:02:07 -0000 Paterson, Kenny wrote: > > Really? I assume you know about CRIME?? Yes, I do. Similar to BEAST, it is *NOT* an attack. It is a pretty boring demonstration of the principle of operation of querying an encryption oracle (BEAST) or compression oracle (CRIME). None of the alleged "fixes" against BEAST and CRIME addresses the real vulnerability. Even with compression disabled and TLSv1.1+ or AEAD cipher suites, the vulnerability is WIDE OPEN. The attackers code could, rather than performing a demonstration of a boring principle, submit any attacker-desired nefarious request to the server, the Browser will blissfully insert the authentication-credentials into that nefarious request, and the server will blissfully execute the request. No matter what fancy stuff the TLS WG puts into TLSv1.3, the attack will continue to work as long as the browser keeps doing the stupid stuff: volutarily and blissfully inserting authentication credentials into requests that the browser performs on the attackers behalf. -Martin From nobody Wed Mar 26 15:16:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E181A03DB for ; Wed, 26 Mar 2014 15:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goRVwl8hwayj for ; Wed, 26 Mar 2014 15:16:17 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFBB1A03CB for ; Wed, 26 Mar 2014 15:16:17 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id m5so2935021qaj.39 for ; Wed, 26 Mar 2014 15:16:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:content-transfer-encoding:subject :references:from:mime-version:in-reply-to:message-id:date:cc:to; bh=crzg51W90TBXV/dhSD2yi2Z7BYwhYXHGGcKqu8kw1fU=; b=LuexYFQf1keAeO9ebHm+TDPQXBzZT3p+mmgKc2nyjYGbcpa6YzA04xaHIxHlHYpcYh DrccYVaqGJeJiN4YY9sRQQGj9RQbOxo7pzOOwTYrperySt/DK/78LdlUEiUFmvIErb29 ssyGmeZFKBd3Ycmj7dyRb7qD3mgvhmicectCsvRW9fc3os4wIH/HY5k64yKJCMHndSJG QsdknyqiiSLlGSjiznS6sNnQ3DxG5KiHdQlspmek+vwkXBX2DDzdxH7x6z5h1KWRQLWP Fbf4IUj7sLIM10oFWnQ75ncB1AdnpGLLxpDEf7YQwTuC9cbpN/Cib29NqPXqWO1ZNKA4 mddw== X-Gm-Message-State: ALoCoQludc1sNkXQyaKzy9fSvABuTyB/6RjB6XQSAHhVNAs1xCBHT3/WfGnoTdzXPfXEnGjYtVxC X-Received: by 10.229.66.133 with SMTP id n5mr93041412qci.0.1395872175333; Wed, 26 Mar 2014 15:16:15 -0700 (PDT) Received: from [10.144.212.182] (mobile-166-171-059-220.mycingular.net. [166.171.59.220]) by mx.google.com with ESMTPSA id s13sm19235qag.19.2014.03.26.15.16.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Mar 2014 15:16:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: <20140326220200.6A9781AC7D@ld9781.wdf.sap.corp> From: Eric Rescorla Mime-Version: 1.0 (1.0) In-Reply-To: <20140326220200.6A9781AC7D@ld9781.wdf.sap.corp> Message-Id: <5EED826F-4736-4331-B7B8-8C73DA6F5ACA@rtfm.com> Date: Wed, 26 Mar 2014 18:14:25 -0400 To: "mrex@sap.com" X-Mailer: iPhone Mail (11D167) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Oj1RUo0XA1QiaWCu4PyArvWOYaQ Cc: "tls@ietf.org" Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Mar 2014 22:16:20 -0000 > On Mar 26, 2014, at 18:02, mrex@sap.com (Martin Rex) wrote: >=20 > Paterson, Kenny wrote: >>=20 >> Really? I assume you know about CRIME?? >=20 > Yes, I do. Similar to BEAST, it is *NOT* an attack. > It is a pretty boring demonstration of the principle of operation > of querying an encryption oracle (BEAST) or compression oracle (CRIME). >=20 > None of the alleged "fixes" against BEAST and CRIME addresses the > real vulnerability. Even with compression disabled and TLSv1.1+ or > AEAD cipher suites, the vulnerability is WIDE OPEN. The attackers > code could, rather than performing a demonstration of a boring > principle, submit any attacker-desired nefarious request to the > server, the Browser will blissfully insert the authentication-credentials > into that nefarious request, and the server will blissfully execute > the request. =20 This is more an http issue than a tls issue but we pretty much have to go wi= th the Web we have which includes (restricted) cross origin requests subject= to the same origin policy. EKR > No matter what fancy stuff the TLS WG puts into TLSv1.3, > the attack will continue to work as long as the browser keeps doing > the stupid stuff: volutarily and blissfully inserting authentication > credentials into requests that the browser performs on the attackers > behalf. >=20 >=20 > -Martin >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Mar 26 15:21:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BA21A03DC for ; Wed, 26 Mar 2014 15:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmA8y9LePDPM for ; Wed, 26 Mar 2014 15:21:49 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) by ietfa.amsl.com (Postfix) with ESMTP id 87E871A03DB for ; Wed, 26 Mar 2014 15:21:49 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id q200so1437543ykb.36 for ; Wed, 26 Mar 2014 15:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yag/opBLYZNg05GhPkLCf5T0vVQZ9HyXuK3+FsQGTh4=; b=kgyPd9oUu7fBDXC3z3ffNcd0yE2AsrXBOnENEfc2fFSC96F2DTw1lgOSoqorM9Ig3q kkbfncTbqXaHgxk2JY01PfelmCOC2a478GuCSv3TIqRCnxzm/9CN1fKQjKDESasg4DtV eqpqHxjbHW2DZxIXah30+GsXDY11nljfePDq3crOyE2lThu24PX+9IpWoDCuTXyja+xj p7bAwWoQoBx6ZA9odks8xApY6xOwus4q4L5hhenAI96ur6oS0UMVf3kA+4uMOmyVfWyH a5CBkpLkw2NbYnf091joMCpS7GH+MSOGQvDKizpNpJ9pYdq8eul7Ut43XxVI0zivzmDE DfGg== MIME-Version: 1.0 X-Received: by 10.236.134.71 with SMTP id r47mr39676196yhi.83.1395872507913; Wed, 26 Mar 2014 15:21:47 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Wed, 26 Mar 2014 15:21:47 -0700 (PDT) In-Reply-To: <20140326220200.6A9781AC7D@ld9781.wdf.sap.corp> References: <2E8232FA-CFDF-42AA-A405-0B080EFE0135@rhul.ac.uk> <20140326220200.6A9781AC7D@ld9781.wdf.sap.corp> Date: Wed, 26 Mar 2014 18:21:47 -0400 Message-ID: From: Watson Ladd To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iHJ5U99ZAk9g6JrS1knsye9yq_0 Cc: "tls@ietf.org" Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Mar 2014 22:21:51 -0000 On Wed, Mar 26, 2014 at 6:02 PM, Martin Rex wrote: > Paterson, Kenny wrote: >> >> Really? I assume you know about CRIME?? > > Yes, I do. Similar to BEAST, it is *NOT* an attack. > It is a pretty boring demonstration of the principle of operation > of querying an encryption oracle (BEAST) or compression oracle (CRIME). > > None of the alleged "fixes" against BEAST and CRIME addresses the > real vulnerability. Even with compression disabled and TLSv1.1+ or > AEAD cipher suites, the vulnerability is WIDE OPEN. The attackers > code could, rather than performing a demonstration of a boring > principle, submit any attacker-desired nefarious request to the > server, the Browser will blissfully insert the authentication-credentials > into that nefarious request, and the server will blissfully execute > the request. No matter what fancy stuff the TLS WG puts into TLSv1.3, > the attack will continue to work as long as the browser keeps doing > the stupid stuff: volutarily and blissfully inserting authentication > credentials into requests that the browser performs on the attackers > behalf. This is called a CSRF, and has been known for a long time. The solution is to use capability-like URLs, with unguessable content. BEAST goes further: it exposes to the adversary credentials, rather than letting the adversary use some of them through controllable means. Sometimes you need to take advantage of this browser behavior: OAuth I believe relies on being able to make cross-site requests with the user credentials, as does single-sign-on. Furthermore, BEAST also affects VPNs built on TLS, where you don't have an option but to pass possibly adversarially influenced traffic. Sincerely, Watson Ladd > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Mar 26 15:34:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E439E1A03EB for ; Wed, 26 Mar 2014 15:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQy8hzS2gg4S for ; Wed, 26 Mar 2014 15:34:45 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 669E51A03E9 for ; Wed, 26 Mar 2014 15:34:45 -0700 (PDT) Received: by mail-yk0-f174.google.com with SMTP id 20so1454107yks.33 for ; Wed, 26 Mar 2014 15:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P1mD36wS93r+Huq1qfnGXZT4qSVOYVgfL3lTTQ2qak8=; b=VEqxVONS+0DzdKrOWLZZD2HDXvmf1uf0xQVAyjd9lA5yDm/5RlpvpqxJHbBjJlIO9r kplQS/dWhqolqOg1Ml9GnIIzQ6GycBNvK4iz5WciG/uM68J13o5juwpO3nl1o7EFK2lg GPvZHTAO5mtDkXq+grbfNjSijVbRMd9Wpf7tPIbx5n92wb5wU//8DzSuiEOonL0iWqfU TxQfmpoxOzIh9vglbXsuVP6q0OLQLENNlZNpOVExAZTWEfmiqOXHHKdOwzrG6GuBXEjf Elqqlp45tPCewKF9RAM/XRc/dRQ12vlTZ4tZgMK2mEo4r0Z7aBwGoLKg6BASWEi72YpU jG/Q== MIME-Version: 1.0 X-Received: by 10.236.79.134 with SMTP id i6mr86084903yhe.16.1395873283746; Wed, 26 Mar 2014 15:34:43 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Wed, 26 Mar 2014 15:34:43 -0700 (PDT) In-Reply-To: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> Date: Wed, 26 Mar 2014 18:34:43 -0400 Message-ID: From: Watson Ladd To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ACHj_wWU8FOohUZxRJMMIMQjJt8 Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 22:34:48 -0000 On Wed, Mar 26, 2014 at 5:12 PM, Martin Rex wrote: > Joseph Salowey (jsalowey) wrote: >> >> TLS has had cipher suites based on RSA key transport (aka "static RSA", >> TLS_RSA_WITH_*) since the days of SSL 2.0. These cipher suites have >> several drawbacks including lack of PFS, pre-master secret contributed >> only by the client, and the general weakening of RSA over time. >> It would make the security analysis simpler to remove this option from >> TLS 1.3. RSA certificates would still be allowed, but the key >> establishment would be via DHE or ECDHE. The consensus in the room >> at IETF-89 was to remove RSA key transport from TLS 1.3. If you have >> concerns about this decision please respond on the TLS list by >> April 11, 2014. > > To me that looks like a pretty bogus statement. > > There really is nothing wrong with static RSA, and I can conceive a > number of scenarios where (EC)DHE could make the situation much worse. > > DHE has the problem that it lacks a required set of parameters. > Generating everything anew and having to verify all parameters > on the client side for each and every handshake is prohibitively expensive, > so a number of implementations seem to be using a static keypair for the > server that is manually generated by an admin once, and never refreshed/ > updated, making it appear better than static RSA, but de-facto much > worse. Small devices that currently have poor entropy sources may > be much better off with a static RSA keypair once generated by an > admin on a machine with good entropy and then pushed onto the device > rather then having to frequently generate new keys on such a device. If the admin is provisioning the devices, they can seed the devices with entropy, which gets irreversibly mixed each power cycle. But yes, DHE parameter validation is a big issue. > > > If RSA was weak, _any_single_use_ of RSA would make you "vulnerable", > not just the RSA encryption of the premaster secret, but in just the > same fashion the RSA signature on the (EC)DHE parameter in the > ServerKeyExchange handshake message. Or the signatures on the > certificate chain, or the signatures on the OCSP responses or CRLs. RSA signatures in the PKI are being increased in size to 2048 and 4096 over the next few years to address this problem. This doesn't seem to be in the cards for static RSA because of the speed issues. > > And once you do the whole PKI glory (long and complex certificate chains > and full revocation galore, then you may realize that RSA still has > a significant performance advantage over the alternatives. For a single signature, maybe. But for multiple signatures with the Schnorr scheme (or ECDSA plus a single extra bit... why wasn't this bit included?) you can batch verify. This has a significant performance advantage. Furthermore, this is orthogonal to the issue of the fastest TLS handshake. RSA decryption is very slow, so you can do the two exponentiations to complete a P256 handshake and signing in the time to encrypt. The client doesn't matter: it is making very few connections, so can take a while to do the calculations. Sincerely, Watson Ladd > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Mar 26 16:25:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621551A0276 for ; Wed, 26 Mar 2014 16:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpR9ZbkWJTsx for ; Wed, 26 Mar 2014 16:25:03 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id AE98E1A024D for ; Wed, 26 Mar 2014 16:25:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,738,1389762000"; d="scan'208";a="2404706" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 26 Mar 2014 19:25:01 -0400 Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([::1]) with mapi id 14.02.0247.003; Wed, 26 Mar 2014 19:25:01 -0400 From: Santosh Chokhani To: "mrex@sap.com" , "Joseph Salowey (jsalowey)" Thread-Topic: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 Thread-Index: AQHPSTgYIMQ+i3GfNEGBIytwQbpiBZr0AJNw Date: Wed, 26 Mar 2014 23:25:00 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E81139174CF2@scygexch10.cygnacom.com> References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> In-Reply-To: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.24.98] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7n_i4FgxnYwWiTdlvIS1ibbmcMI Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 23:25:07 -0000 Martin, While I agree with most of what you say including some benefits of RSA, the= DHE parameter verification by the client while desirable is not a genuine = security threat. A rogue server has many other ways to compromise the exch= ange, -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex Sent: Wednesday, March 26, 2014 5:12 PM To: Joseph Salowey (jsalowey) Cc: tls@ietf.org Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from = TLS 1.3 Joseph Salowey (jsalowey) wrote: > > TLS has had cipher suites based on RSA key transport (aka "static RSA", > TLS_RSA_WITH_*) since the days of SSL 2.0. These cipher suites have > several drawbacks including lack of PFS, pre-master secret contributed=20 > only by the client, and the general weakening of RSA over time. > It would make the security analysis simpler to remove this option from=20 > TLS 1.3. RSA certificates would still be allowed, but the key=20 > establishment would be via DHE or ECDHE. The consensus in the room at=20 > IETF-89 was to remove RSA key transport from TLS 1.3. If you have=20 > concerns about this decision please respond on the TLS list by April=20 > 11, 2014. To me that looks like a pretty bogus statement. There really is nothing wrong with static RSA, and I can conceive a number = of scenarios where (EC)DHE could make the situation much worse. DHE has the problem that it lacks a required set of parameters. Generating everything anew and having to verify all parameters on the clien= t side for each and every handshake is prohibitively expensive, so a number= of implementations seem to be using a static keypair for the server that i= s manually generated by an admin once, and never refreshed/ updated, making= it appear better than static RSA, but de-facto much worse. Small devices = that currently have poor entropy sources may be much better off with a stat= ic RSA keypair once generated by an admin on a machine with good entropy a= nd then pushed onto the device rather then having to frequently generate ne= w keys on such a device. If RSA was weak, _any_single_use_ of RSA would make you "vulnerable", not j= ust the RSA encryption of the premaster secret, but in just the same fashio= n the RSA signature on the (EC)DHE parameter in the ServerKeyExchange hands= hake message. Or the signatures on the certificate chain, or the signature= s on the OCSP responses or CRLs. And once you do the whole PKI glory (long and complex certificate chains an= d full revocation galore, then you may realize that RSA still has a signifi= cant performance advantage over the alternatives. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Wed Mar 26 16:28:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2D11A024D for ; Wed, 26 Mar 2014 16:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwLLSS69r0QU for ; Wed, 26 Mar 2014 16:28:34 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 73BC21A0380 for ; Wed, 26 Mar 2014 16:28:34 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s2QNSRlj027405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Mar 2014 00:28:27 +0100 (MET) In-Reply-To: To: Watson Ladd Date: Thu, 27 Mar 2014 00:28: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: <20140326232827.85DF91AC7D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-cM7wZRSSrEEh_VdtMkl_3yw9P0 Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3< X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 23:28:36 -0000 Watson Ladd wrote: >> >> If RSA was weak, _any_single_use_ of RSA would make you "vulnerable", >> not just the RSA encryption of the premaster secret, but in just the >> same fashion the RSA signature on the (EC)DHE parameter in the >> ServerKeyExchange handshake message. Or the signatures on the >> certificate chain, or the signatures on the OCSP responses or CRLs. > > RSA signatures in the PKI are being increased in size to 2048 and 4096 > over the next few years to address this problem. This doesn't seem to > be in the cards for static RSA because of the speed issues. > > Furthermore, this is orthogonal to the issue of the fastest TLS > handshake. RSA decryption is very slow, so you can do the two > exponentiations to complete a P256 handshake and signing in the time > to encrypt. The client doesn't matter: it is making very few > connections, so can take a while to do the calculations. When using an RSA server certificate the server can choose between having to perform static RSA key exchange with an RSA private key (decryption) operation on the RSA PremasterSecret or an RSA Private key (signature) operation to sign the ServerKeyExchange handshake message --and that signature covers ClientHello.random and ServerHello.random so is unique per full handshake, just like the RSA decryption of the Premaster secret. Where exactly do you see a performance _advantage_ of an RSA-signed (EC)DHE key exchange vs. an RSA-decrypted PremasterSecret? -Martin From nobody Wed Mar 26 17:01:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897511A0408 for ; Wed, 26 Mar 2014 17:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_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 EEDjfsebE9BP for ; Wed, 26 Mar 2014 17:01:18 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 07A761A03FB for ; Wed, 26 Mar 2014 17:01:17 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 200so1548284ykr.31 for ; Wed, 26 Mar 2014 17:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=mjY/LEGnp8dgqnOkmxfGbE3YynzvLOZDnypdRwbMkoA=; b=SjhaY/u1p9c3MvQCvTle7clQtF84YWgItTei37xifcBrfL18tu2luC1MSnfvtyTklJ uytVl9rduLsATZnZpMBkXvAKrXd3P0JopEjcOLyG759mm3ab03zb0s5+f42WSxoyhE3D ZtiN1BvX3NFaEGxeRCl4HLVf2NAmzV5VfuDKFMN4scvR4/VtZNi/DAJYNpVMIK2m1wv1 9PGZTe2lQPB1dV1DMABqN8pW03ayK52Wl+rWLr69bqzDdpLpnePhmAwGfKDEnYEjhwQ1 aS6jalJ9mkb5nvfx6ClsIJ4ac0bd+7bHUibVT1jy4prGqkAsyJd8a4Ymx+I9Z20PAYJS WnCg== MIME-Version: 1.0 X-Received: by 10.236.141.113 with SMTP id f77mr6400274yhj.128.1395878475926; Wed, 26 Mar 2014 17:01:15 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Wed, 26 Mar 2014 17:01:15 -0700 (PDT) Date: Wed, 26 Mar 2014 20:01:15 -0400 Message-ID: From: Watson Ladd To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rVjg1RL4m-mXDyLjZSM-pkYn7mU Cc: "tls@ietf.org" Subject: [TLS] TLS handshake performance (was Re: Confirming Consensus on removing RSA key Transport from TLS 1.3<) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 00:01:19 -0000 On Wed, Mar 26, 2014 at 7:28 PM, Martin Rex wrote: > Watson Ladd wrote: >>> >>> If RSA was weak, _any_single_use_ of RSA would make you "vulnerable", >>> not just the RSA encryption of the premaster secret, but in just the >>> same fashion the RSA signature on the (EC)DHE parameter in the >>> ServerKeyExchange handshake message. Or the signatures on the >>> certificate chain, or the signatures on the OCSP responses or CRLs. >> >> RSA signatures in the PKI are being increased in size to 2048 and 4096 >> over the next few years to address this problem. This doesn't seem to >> be in the cards for static RSA because of the speed issues. >> >> Furthermore, this is orthogonal to the issue of the fastest TLS >> handshake. RSA decryption is very slow, so you can do the two >> exponentiations to complete a P256 handshake and signing in the time >> to encrypt. The client doesn't matter: it is making very few >> connections, so can take a while to do the calculations. > > When using an RSA server certificate the server can choose between having > to perform static RSA key exchange with an RSA private key (decryption) > operation on the RSA PremasterSecret or an RSA Private key (signature) > operation to sign the ServerKeyExchange handshake message > --and that signature covers ClientHello.random and ServerHello.random > so is unique per full handshake, just like the RSA decryption of the > Premaster secret. > > Where exactly do you see a performance _advantage_ of an RSA-signed > (EC)DHE key exchange vs. an RSA-decrypted PremasterSecret? Not RSA signed, but ECDSA signed. Three exponentiations vs. one RSA private key operation. Using openssl speed I got that ECDH+ECDSA is twice as fast as RSA. If you are stuck with an RSA server key, you can use a semistatic ECDSA key, and do exactly one exponentiation per connection, plus one RSA private key operation per key rotation interval. There is a reason large sites use ECDHE-ECDSA. If I remember correctly, switching the key the server uses for clients doesn't require a new certificate, but I might be wrong. Sincerely, Watson Ladd > > -Martin -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Mar 26 17:04:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CF21A0406 for ; Wed, 26 Mar 2014 17:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.552 X-Spam-Level: X-Spam-Status: No, score=-5.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_BACKHAIR_57=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlxORhB-YQPf for ; Wed, 26 Mar 2014 17:04:34 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id F17071A03FE for ; Wed, 26 Mar 2014 17:04:33 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s2R04Vlg004504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Mar 2014 01:04:31 +0100 (MET) In-Reply-To: <5EED826F-4736-4331-B7B8-8C73DA6F5ACA@rtfm.com> To: Eric Rescorla Date: Thu, 27 Mar 2014 01:04:31 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140327000431.2C8821AC7D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Jy8BPGTMRCSZUdPtlV08h35oxrM Cc: "tls@ietf.org" Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 00:04:36 -0000 Eric Rescorla wrote: > > This is more an http issue than a tls issue but we pretty much have > to go with the Web we have which includes (restricted) cross origin > requests subject to the same origin policy. Eric, in principle I'm with you. The TLS WG needs to take into account real world usage scenarios or it will cease to be a useful technology. But we are having a real problem that folks a looking at TLS to be "magic pixie dust", and the perception that any apps or protocol design, no matter what design flaws it has, will automatically become secure by adding TLS to it. I don't see a solution for the disclosing authentication (=passwords) at the human<->machine interface, not even on the horizon. But the disclosing authentication on pure machine<->machine interfaces (including "SSL Cookies") provides ample opportunity for new security problems, and I'm seeing that TLS channel encryption is (ab)used to excuse the continued use of disclosing authentication on what is pure machine<->machine interfaces, and that train is heading in the wrong direction. -Martin From nobody Wed Mar 26 23:33:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD21A1A029E for ; Wed, 26 Mar 2014 23:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.13 X-Spam-Level: X-Spam-Status: No, score=-101.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcTCfDzjlcqa for ; Wed, 26 Mar 2014 23:33:08 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id AC4771A0295 for ; Wed, 26 Mar 2014 23:33:08 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 83D8F9A43D6; Thu, 27 Mar 2014 02:32:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id X+dLNf5Agfmv; Thu, 27 Mar 2014 02:32:36 -0400 (EDT) Received: from [10.59.80.125] (unknown [210.229.158.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 36EBC9A43CA; Thu, 27 Mar 2014 02:32:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> Date: Thu, 27 Mar 2014 02:32:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3EAC453F-7902-48FC-B255-4416F50BBF82@vigilsec.com> References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> To: Joseph Salowey (jsalowey) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KrVLuHdGUgHYafiBIsPNc4ygwrU Cc: "" Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 06:33:10 -0000 I'd like to ask a clarifying question. Please look at RFC 6476. In that document, Peter Gutmann uses = traditional encryption and integrity functions to make an AEAD cipher. = Does this decision allow or prohibit such ciphers? Russ On Mar 26, 2014, at 2:43 PM, Joseph Salowey (jsalowey) wrote: > TLS has supported a number of different cipher types for protecting = the record layer. In TLS 1.3 these include Stream Cipher, CBC Block = Cipher and AEAD Cipher. The construction of the CBC mode within TLS has = been shown to be flawed and stream ciphers are not generally applicable = to DTLS. Using a single mechanism for cryptographic transforms would = make security analysis easier. AEAD ciphers can be constructed from = stream ciphers and block ciphers and are defined as protocol independent = transforms. The consensus in the room at IETF-89 was to only support = AEAD ciphers in TLS 1.3. If you have concerns about this decision please = respond on the TLS list by April 11, 2014. >=20 > Thanks, >=20 > Joe > [Speaking for the TLS chairs] >=20 From nobody Thu Mar 27 01:30:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83CC1A04A6 for ; Thu, 27 Mar 2014 01:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 HgTKw7VyFnk4 for ; Thu, 27 Mar 2014 01:30:50 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4441A049F for ; Thu, 27 Mar 2014 01:30:49 -0700 (PDT) Received: from secworks82.gotanet.se (unknown [62.80.223.82]) by mail.frobbit.se (Postfix) with ESMTPSA id 1D16B20164; Thu, 27 Mar 2014 09:30:47 +0100 (CET) Message-ID: <5333E1B5.2060601@secworks.se> Date: Thu, 27 Mar 2014 09:30:45 +0100 From: =?ISO-8859-1?Q?Joachim_Str=F6mbergson?= User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Martin Thomson References: <53332D3D.5020908@gmail.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Gb-liKCQhTsqHib98LH_Xxm1n0M Cc: "" Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: joachim@secworks.se List-Id: "This is the mailing list 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, 27 Mar 2014 08:30:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Aloha! Martin Thomson wrote: > The general trend I've observed in these discussions is to move the > decision to compress closer to the application. This means that the > decision can be informed better by context. Generically applied > compression is necessarily less aware of constraints on its use. Yes, good point. And imho compression is not something you add to get security. It might alleviate overhead caused by a secure tunneling mechanism. But it is not really a required feature. Separation of duty. If one really want compression, use one of the available compression protocols and tunnel the result through TLS for the security. Or better yet, as Martin says, put it as close to the application layer as possible. - -- Med vnlig hlsning, Yours Joachim Strmbergson - Alltid i harmonisk svngning. ======================================================================== Joachim Strmbergson Secworks AB joachim@secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJTM+G1AAoJEF3cfFQkIuyNQRQQAIpN9toxSZgckekZoRa5ovbA dvLGlkBdNSpFmJym72/9xC8IdO4puQjPT6Aj+fofO6BdL5OAR6/1j60CMMMF5SMj IdYgRv3zo13YDgcC1zs+gYPeqEP+XQhY2yE598ifo/BWWq9fJtGlO2Eh0R4ZkO7I 81ANwoetnTQcGILAXknZv9elrC4sm7Jq4xHXaBCDiYC6a7NUxW7AbHJJdAJVNL+j bYiLQ/fuXKSbUgXbyAnbjip81lUKU5QorLpZMcF7n6C5YEED+eO4K7kXEZmfMn0D oFd5cnaDau842p7wfWamNDEKFQemTzJii8SSHSdu4PRbNGebGNTDcXv52dJWIdts 7SVZNT8l+JKMr5HoO0enZFXkm+IwNjXWd1xzMtg2l7nNhN6PAAa4rpG72jzWk7Ba Jo8dYW7+a9JiJDiSCNz+FI2F/fMwf++DzRlP7KGHCUcEIb1sesjWzO9tk64ZKoZy pM0+WNt0EyCU+4g5gPH6xa8TjgKM3j3JIgEUc1Mzf3xWzix7u2NveQfC23m9qmVi Hx8FUFwTqlH0C3NF9wJMeV9ZlGB02YS8DOSZOj2BqHJyOZFXiXusK0qhq4zBA6p/ UiiQFcURaiRGLbVjCFB6NQrbNRMY/0F1uR5hTxEux0CfW1ygTF5ep3of+bswyYDi BsKRLXLBNJLYEuT+8f9t =iAnB -----END PGP SIGNATURE----- From nobody Thu Mar 27 01:56:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCD31A049D for ; Thu, 27 Mar 2014 01:56:14 -0700 (PDT) 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_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz003dgj0n00 for ; Thu, 27 Mar 2014 01:56:12 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id B6F931A0478 for ; Thu, 27 Mar 2014 01:56:12 -0700 (PDT) Received: from localhost (91-66-83-156-dynip.superkabel.de [::ffff:91.66.83.156]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 27 Mar 2014 09:56:10 +0100 id 000000000002001B.000000005333E7AA.00005F18 Date: Thu, 27 Mar 2014 09:55:27 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20140327095527.5335c7fa@hboeck.de> In-Reply-To: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-24344-1395910570-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ag15PJeUQRCUwJtiudybDVB-F7U Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 08:56:14 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-24344-1395910570-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 26 Mar 2014 22:12:19 +0100 (CET) mrex@sap.com (Martin Rex) wrote: > DHE has the problem that it lacks a required set of parameters. > Generating everything anew and having to verify all parameters > on the client side for each and every handshake is prohibitively > expensive, so a number of implementations seem to be using a static > keypair for the server that is manually generated by an admin once, > and never refreshed/ updated, making it appear better than static > RSA, but de-facto much worse. Appart from the other issues, I think it would make a lot of sense to change DHE handling in TLS 1.3 away from "server can have arbitrary parameters". The authors of the triple handshake attack have proposed having a set of "known good" parameters and I think this is the way to go for TLS 1.3 and DHE. It's probably enough to say "we define a 2048 and a 4096 DH parameter set with tested and known primes" and allow the option to easily define more if there ever is a need to say "we need 8192 bit DHE now". --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-24344-1395910570-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJTM+d/AAoJEKWIAHK7tR5CQsMQALfrPDzBkB0rUXi7fp9CUHMG tQ/Uq2mg/GV4V1caoEQhye8pDr/1g6IK2B8s5b4eBqJQB+7r3aCiPwa8JOiGUxpe zKtEvUNDqyfstUnzD4spVTmVwQFZcBItlZ+4YzGoxhMfYBWxvupmJu3miI+G+zse KCFoqnzMMjjCSaS3bH3dNgKh2QGI9Yuio1iMEpWNIEq8Rcq3VvuenyYBKhv2qpDN n+KeV/J6T7K2EUmi3KhHd3BfjaKA9WcMnih3H3D3WZPRLlnft05NOIe1/GJWiPrg 6W1eOOjr9JkVE6euoYD7SzqyC/en/f9n7uLwnwCGz7tiDeqdAyEMcMMvFgi5fkFy gBfYuIB958FeXLUGEVghwZrRSXPIng7Oj4IgHwrAT9+Lp37hCphBy7/qRQfuyMfJ hatQMnvyOD1JKcieYb0/GhrOqWIOa2wW/z7TmFmepldQfzZXOc4l8mNYyWtMKyOQ dTEW3bIRPz9TbRSebAvCUFx4V6U5/YfFYJvGAaA4yOsk2a4dwOm4suqiXslqKcCz xgQsffUf/AO5RRFvUV6IiKeG2B8tS33yzXwc/8ajiO5mYsQgJwJUNUMJ/1d/+C6M muVFhogpH5p6yl/6bfIUUD58IjfhNO45+vYB4xzJRH1/8zzyV3ZR5NP2RxKQ1a66 rXuh/BZb1zMD87fFrZ76 =Ld4A -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-24344-1395910570-0001-2-- From nobody Thu Mar 27 02:19:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988D41A04A3 for ; Thu, 27 Mar 2014 02:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NH-0gfTyxa7m for ; Thu, 27 Mar 2014 02:19:05 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9C01A0305 for ; Thu, 27 Mar 2014 02:19:05 -0700 (PDT) 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 s2R9J3xg017370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Mar 2014 05:19:03 -0400 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 s2R9J0et027850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 27 Mar 2014 05:19:02 -0400 Message-ID: <1395911940.19721.0.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Trevor Perrin Date: Thu, 27 Mar 2014 10:19:00 +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.25 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5H6jzusdvWrbYoH8kOwSrKmwVOY Cc: tls@ietf.org Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 09:19:06 -0000 On Wed, 2014-03-26 at 12:30 -0700, Trevor Perrin wrote: > Hi Joe, > > Could you explain what the process for TLS 1.3 is? > > It seems like you want the group to start making lots of small, > specific decisions. I'm not convinced that's the best way to design a > complex protocol with lots of inter-related pieces. > > I was hoping we'd have some discussion on the TLS 1.3 process, now > that the charter is approved. Is that not going to happen? I second that. regards, Nikos From nobody Thu Mar 27 04:55:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364021A0658 for ; Thu, 27 Mar 2014 04:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA0ZU1_0X4QV for ; Thu, 27 Mar 2014 04:55:55 -0700 (PDT) Received: from maple.randombit.net (maple.randombit.net [66.228.45.112]) by ietfa.amsl.com (Postfix) with ESMTP id F3BD31A031A for ; Thu, 27 Mar 2014 04:55:54 -0700 (PDT) Received: from oak.randombit.net (oak.randombit.net [50.116.63.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by maple.randombit.net (Postfix) with ESMTPS id 2FE3BA0653 for ; Thu, 27 Mar 2014 07:55:52 -0400 (EDT) Received: by oak.randombit.net (sSMTP sendmail emulation); Thu, 27 Mar 2014 07:55:51 -0400 From: "Jack Lloyd" Date: Thu, 27 Mar 2014 07:55:51 -0400 To: tls@ietf.org Message-ID: <20140327115551.GA24503@randombit.net> Mail-Followup-To: tls@ietf.org References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140327095527.5335c7fa@hboeck.de> X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-PGP-Key: http://www.randombit.net/pgpkey.html User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/96kgkAQb5SCroiv6wqq4DXv57SE Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 11:55:56 -0000 On Thu, Mar 27, 2014 at 09:55:27AM +0100, Hanno Bck wrote: > Appart from the other issues, I think it would make a lot of sense to > change DHE handling in TLS 1.3 away from "server can have arbitrary > parameters". +1; it is simpler, saves handshake bytes, and prevents misconfigured servers from doing stupid things like 512-bit DH. Something very much like the existing EllipticCurveList (_without_ the explicit curve option) seems like it would work well. ~Jack From nobody Thu Mar 27 05:27:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6414A1A0690 for ; Thu, 27 Mar 2014 05:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, 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 8w3GHnmUR2ew for ; Thu, 27 Mar 2014 05:27:23 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id B38731A068A for ; Thu, 27 Mar 2014 05:27:23 -0700 (PDT) Received: from [10.103.236.114] (94.197.120.139.threembb.co.uk [94.197.120.139]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by entima.net (Postfix) with ESMTPSA id E6B8C600FE for ; Thu, 27 Mar 2014 12:27:20 +0000 (GMT) User-Agent: K-9 Mail for Android In-Reply-To: <20140327115551.GA24503@randombit.net> References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <20140327115551.GA24503@randombit.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Thu, 27 Mar 2014 12:27:17 +0000 To: tls@ietf.org Message-ID: <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3CSfk7pjZ4eKMNDIlWMoD-iWl5M Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 12:27:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Mar 27, 2014 at 09:55:27AM +0100, Hanno Böck wrote: > Appart from the other issues, I think it would make a lot of sense to > change DHE handling in TLS 1.3 away from "server can have arbitrary > parameters". I'm wondering: why even keep DHE around at all? Let's face it: traditional DHE runs like an absolute dog compared to ECDHE using secp256r1, or especially curve25519 (which we have a live draft for now: I'm ready to start driving deployment almost as soon as we get a curve number!). Speed is why people were reluctant to deploy PFS, and in many cases in the wild, advised increasing TLS server performance by disabling it (which is bad for everyone). ECDHE eliminates that problem. Show of hands: who *really* wants to deploy 2048-bit (or above) DHE, when they could have curve25519 instead? Suggestion: remove static RSA *and* traditional DHE and mandate ECDHE for key exchange in TLS 1.3. I propose, curve25519 as mandatory-to-implement and secp256r1 as recommended-to-implement [? Also mandatory, maybe?], both in constant time, which is comparatively easy, especially for 25519. That would simplify the protocol considerably (decreasing the code and protocol surface to audit), increase its baseline security well above 2048-bit DH, to ~3072-bit (ish) levels, reduce the size of the exchanges and massively reduce the CPU load on both servers and clients. That seems to me like a win for every one of the good guys and none of the bad guys: TLS 1.3 gets both simpler, easier to audit, more secure *and* faster - and that's the kind of thing that'll drive 1.3 adoption in my opinion. Thoughts? - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJTNBkkGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t67zwQAL0qda+2JX6ODJLzhuvKI6v82ng4cWvNh/OnVZ7CNKKq2JR/AdBj CftYldhG/8ETi4chPhie3q4ovc+uo3NtP1W95zo696s1wPKDYI7/d60SrxvycdSA zStYAmSxK39cXDvm9iyNNGTVPdvwbZAkiQjFGh+pXIN0c8SP4L11FtDaVhe/7/Ee 4Fn2cpSe9FojMbB7XYqO9QIeLsUzeEgfNBdL58P9ZbpkBK7SsHzu9u5LSSh+vtsF ejbgwuvaPxDuRVGgKffI3lSUC4GCm0krqgou1eDM2uWMKoBydSOC4JMFbZDWrMrC 1CHDpnyhgU9a6dnBbI6W3mf/vrIddHeN2PAQHyAC7aRhMrMgLqNN7SuXo4ifFmco tbSNCyiTguYE1juOMsxwMSRGjd0AMM3TSkY85COduWiEjvekfVyuT540CClqrar/ JqHgdo69SjNDT24sGfcMpji/5Hklg+pkUPX/pX9yVzZPUvfER6bRhnb2FaHFvvx0 rPBO/VOgTIP+0DRPYcSNVrkSymFSNs2wBwf8D3FrPa+6gKfByFIelLDY68nDs9O8 v2r+iiNIKKp97CNYJPvzx2srR7IDJF908ZA7U5v5fmUs3+JEV1VxRONwtxj+hJj4 qbQSdOwF/n8uRRsEZ+Z8vAbdo35j8v0DHCnn8T3DxE1qE1ymLFH9XqiK =g6eK -----END PGP SIGNATURE----- From nobody Thu Mar 27 05:37:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F37B1A068D for ; Thu, 27 Mar 2014 05:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9Ub-JYBqM2h for ; Thu, 27 Mar 2014 05:37:36 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 630631A0691 for ; Thu, 27 Mar 2014 05:37:36 -0700 (PDT) Received: from [10.103.236.114] (94.197.120.139.threembb.co.uk [94.197.120.139]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by entima.net (Postfix) with ESMTPSA id 10414600FE for ; Thu, 27 Mar 2014 12:37:33 +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: Thu, 27 Mar 2014 12:37:29 +0000 To: "" Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nCBBOWJX0J_p47Wdr4qGxw10920 Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Mar 2014 12:37:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 26 March 2014 18:42:51 GMT+00:00, "Joseph Salowey (jsalowey)" wrote: >The consensus in the room at IETF-89 was to remove compression from TLS 1.3 >to remove this attack vector. +1 Remove compression. Compression is usually best performed as "high" as possible; transport layer is blind to what's being compressed, which is (as we now know) was definitely too low and was in retrospect a mistake. Any application layer protocol needs to know - if compression is supported - to separate compression contexts for attacker-chosen plaintext and attacker-sought unknown secrets. (As others have stated, HTTPbis covers this.) Any encrypted (or unencrypted) protocol could potentially have a size oracle where compression dictionaries were mixed in that case. That's an issue for the security of the underlying protocol, although I think we should draw strong attention to it and remind implementers that we cannot protect from that (and make no attempt to protect from size oracles in TLS in general). - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJTNBuJGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t66sQP/05Ap4HkgyvUlxuiMWWs2D5MOJT5sXZnd4WYRDML/JpPzKG8GSeQ NIga9dxXa3mpdaW++9xM/KZs+4SH0XvwURsTMapbCPeFCwdSknHvVVD2bC1thKY+ quzeiuNj3I3DGZ6vccgspgzTEePylxDtAU+YP+2+fvYy/Vlsb15OsOw4oIFG9et5 kwY6kJpFGsZpURElJE/zAEOKB8GwXAGJ/4r+gnPmXpP7e9jJxqC0fsLjhwnlx4o4 IR6+gjZ1LYPGswCjfj8kLxNByTE0fCzlg9yGzPkOLUscSQFytGE0TVbivvAKWv6y SPVdlxlKb9NEZPbL6bCBXrj328YbncwJ3sxcMfxxx/mS50ZUSP/USFX7ss1L3wW5 Yr90LjG/O9opAz/xqnX/qTnOBpTENNUu0ZR7Hd0Ha3Nw2BWIqy8jhN6bvK8CWAiN jS2LZSgy8MDfkfjUAAAFX0MDrVTLlt4GKUEj07TtNVOnV2YtdBZy0u76sQ2hes8c V1SNNchJQTldkMjii8IWTo6L4JTGM9zQfaThXIMkUJrNWyvxN9CCJ7WCYA/wHICb Q6oo+j6hMrV653B7NfsD5JaD9mHovkzU2iOVwDZXI6iMvjHsXTWOCB2f10TTKXSk SXzpROPLvM7ZemVKdbmptFJecUNuFqLD4/BY6vBLLM+ZYBSMOAx3AOjY =l/mz -----END PGP SIGNATURE----- From nobody Thu Mar 27 05:37:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF51D1A0067 for ; Thu, 27 Mar 2014 05:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.993 X-Spam-Level: * X-Spam-Status: No, score=1.993 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3ypJCsP6TY5 for ; Thu, 27 Mar 2014 05:37:55 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 79E6B1A0055 for ; Thu, 27 Mar 2014 05:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=offspark.com; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:To:From; bh=SX7BxpphVXTHNGIcpiz/LQMFuzk3vesqEIfS9kBRro8=; b=IMm8A0gJHNHNn3q8XtfYCr3iUxG5AQ5xnNgvHI0SJ9cVKALqVygA60rHMGQeo+wBkQtL75cq8ipWz/Y0CNxsJ+Tk0u5I0GTt1dXPKFMb8znvhsOWCsm48janau1Pl7J/uyx1QPFek2YYJOKPao7+b4wkEfGlUnZ3ZBONWLPET/w=; Received: from a82-161-132-220.adsl.xs4all.nl ([82.161.132.220] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WT9Z3-0005Ri-LU; Thu, 27 Mar 2014 13:37:46 +0100 From: "Paul Bakker" To: "'Alyssa Rowan'" , References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <20140327115551.GA24503@randombit.net> <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> In-Reply-To: <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> Date: Thu, 27 Mar 2014 13:37:43 +0100 Message-ID: <02c101cf49b9$5d080da0$171828e0$@offspark.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFCyZKiN8ZEGaLHNGhiDtIsYJ3IqQINCKjVAjGxmm8CObuRPQI27ptem8hjk0A= Content-Language: nl X-SA-Exim-Connect-IP: 82.161.132.220 X-SA-Exim-Mail-From: p.j.bakker@offspark.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JIqHEI0De05t4XkdJQ-Nc0GFrFw Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 12:37:56 -0000 > Suggestion: remove static RSA *and* traditional DHE and mandate ECDHE = for > key exchange in TLS 1.3. I propose, > curve25519 as mandatory-to-implement and secp256r1 as recommended- > to-implement [? Also mandatory, maybe?], both in constant time, which = is > comparatively easy, especially for 25519. Let's not do that.. The world is bigger that 'Fat clients'. Other key = exchanges, such as pure PSK have their value in very-low-resource = situations. And I think it's never a good idea to depend on a single key exchange = scheme, for future security robustness. > That would simplify the protocol considerably (decreasing the code and > protocol surface to audit), increase its baseline security well above = 2048-bit > DH, to ~3072-bit (ish) levels, reduce the size of the exchanges and = massively > reduce the CPU load on both servers and clients. I do agree that we should make the core as secure as possible, but we = should keep all kinds of clients and servers in mind.. Paul Bakker From nobody Thu Mar 27 05:59:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9371A068D for ; Thu, 27 Mar 2014 05:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiAlLCXEnkVg for ; Thu, 27 Mar 2014 05:59:09 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0886B1A00B4 for ; Thu, 27 Mar 2014 05:59:08 -0700 (PDT) Received: from [10.103.236.114] (94.197.120.139.threembb.co.uk [94.197.120.139]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by entima.net (Postfix) with ESMTPSA id 57E88600FE for ; Thu, 27 Mar 2014 12:59:06 +0000 (GMT) User-Agent: K-9 Mail for Android In-Reply-To: <02c101cf49b9$5d080da0$171828e0$@offspark.com> References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <20140327115551.GA24503@randombit.net> <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> <02c101cf49b9$5d080da0$171828e0$@offspark.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Thu, 27 Mar 2014 12:59:02 +0000 To: tls@ietf.org Message-ID: <3d2bb399-b932-4bc1-89d0-848260e0036d@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BVJTJz86TR4PiL4220QcHg1QviA Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 12:59:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 27 March 2014 12:37:43 GMT+00:00, Paul Bakker wrote: >Other key exchanges, such as pure PSK have their value in very-low-resource >situations. Hmm. Where you're low resource enough to have to pre-share keys, you're specifying your own profile because you know exactly what's connecting (otherwise you couldn't pre-share keys with it). I don't think that's suitably applicable to the general profile for TLS on the internet. Maybe, if you're that constrained, you don't *really* want TLS and its x.509 luggage at all: AES-GCM or ChaCha20-Poly1305 and a monotonic counter nonce? And if you want forward security, and you probably should, then you probably want... curve25519. I certainly don't see how that's a good argument for keeping DHE around, which is the fattest of the key exchanges. Seems rather like the opposite, actually. >And I think it's never a good idea to depend on a single key exchange >scheme, for future security robustness. Agreed, which is part of why I suggested ECDHE over *two* curves: djb's fast curve25519, and NIST's already-deployed and 'Suite Beatified' secp256r1. They're fairly different. We can specify further ones in future if (and hopefully in advance of when) problems arise. Specifying several exchanges might potentially make us vulnerable to the difficulties of both, if the attacker gets to pick which. We *should* safely avoid that of course, but it should be kept in mind. - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJTNCCWGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6EzkQAKJJOpH7xSKAzcP+ENVAMtO3wD+u5z2Q8JLPTwGc4+x+vo8hsPk6 rFXqt2311ENAkGdft99eD7n8xSF03a/WVnSNv6pn20XLeJhXiWPyv6m2onL8+Kv0 wAQbkIp6WN1bb4BvlQ9EVYTWFmxIEZpCW7A1ebi95sdi/Z+ctwS6F5AYBn3DQx2Z 2UVGS0idrcXA1F1js31WfPEggYsAf9AH9jpBV6Ya3233KdGYqlptx4o9vLDY3lZn yojcYKPcRg6e1hCGkTUYr/cckj3qnal3oHjKQBrILRysxPKm4KavDzVRjvrMgwBU C4sQP+mQHm9+ynYcYySrur0uD5f8tFdCgYOHJa3gj9eppfufZxt303SOuLbbyW6k Qoryg/YNeZ6kvIyLRqxbVNACBYamNwVZxnNedZm10VfW6FSr7AE1m58PFyCK8Wu2 v7tacmnCVe+zl6KHKLDcnTaS2iRdM1QwUBOoTdcxvlRddzJTPi0cs5ghRbs5ZCpM fTIaNVGcVPx1GuNUpWu6rhA3U+E+oMojmyVMjJEHQWYXryJoi0MCS+TW0MInrGfW uD4qt2P7RltmZw+qsRKuv6yKs+904LpFqsyMZa+DFVMis5ntvBBMIpyp3eNDX8A/ SpqSypLovgVRKc3oA8TTwvTU+jucVDIUHwU2YQC+gr68rI5gg2wmWuL1 =IABy -----END PGP SIGNATURE----- From nobody Thu Mar 27 06:01:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782FE1A06CB for ; Thu, 27 Mar 2014 06:01:48 -0700 (PDT) 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_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70hAQxPtV7X6 for ; Thu, 27 Mar 2014 06:01:46 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id 635D01A06B9 for ; Thu, 27 Mar 2014 06:01:46 -0700 (PDT) Received: from localhost (91-66-83-156-dynip.superkabel.de [::ffff:91.66.83.156]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 27 Mar 2014 14:01:44 +0100 id 000000000002005A.0000000053342138.00005BCC Date: Thu, 27 Mar 2014 14:01:00 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20140327140100.0b98c4b5@hboeck.de> In-Reply-To: <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <20140327115551.GA24503@randombit.net> <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-23500-1395925304-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YGN2xGyXEufjAIceVwsae9jiGTA Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 13:01:48 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-23500-1395925304-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 27 Mar 2014 12:27:17 +0000 Alyssa Rowan wrote: > I'm wondering: why even keep DHE around at all? >=20 > Let's face it: traditional DHE runs like an absolute dog compared to > ECDHE using secp256r1, or especially curve25519 (which we have a live > draft for now: I'm ready to start driving deployment almost as soon > as we get a curve number!). I'm not comfortable with the idea of going elliptic curve everywhere. I'd really prefer to keep the "old and well tested" options around. There's a particular reason I think so: I think at one point (which may be 10, may be 30 years away or may not happen at all) we'll have to deal with quantum computers. Right now we have nothing really to offer here yet (I'm aware of pqcrypto algos, but none of them is in any usable state right now), but the first defense to quantum computers is increased key sizes. It will be easier to build a quantum computer to break 512 bit keys than one to break 4096 bit keys. That's why in a word where quantum computers become a reality I'd rather go with RSA+DHE with large key/modulus than with anything from the ECC family. Appart from that: From the facts I know I am extremely uncomfortable with both ECDSA and the NIST curves and I'd really like to have them removed from TLS altogether. Strong vote for Ed25519 (or another algorithm with similar properties) and only curves that pass the safecurves criteria. --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-23500-1395925304-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJTNCEMAAoJEKWIAHK7tR5C2s8QAMQzIweLo8rJv79JOMxN7/WN 1JS7qqeMlf0Pkj+d3ZTtFA8Rfd8Z6isH2JYipKxJp2dnoh6IHHPUki7xT9ZsoPsP 84oGZuejWcYsbsGeC4kvRykk7QkyqdFJd/N0Qtvui5MtPg4Yl7TZrTknWy2HWj5Q L2qW7jIr2F9KJEIo1MSUbbClqXBZhjACB9JVsmUHbuP6kyg2qt8yWTpD66scxsPp jDPf6ZQ5dYZf3PA9mq3OgZkquZCW/jPhq9skG/7Zw/aHhWAS40uAfHlU+vcO1KO3 biEWcZ5NwhAX0IIontYAfb7EiKGcEYKId1niownWosTknqvgsddipUOMxU+kuBag s4FhV0JXR3Ap+J7MkOLS1vTE8EDmG+zSeO5rxxxOdIiZ3H5HlceGDLW1gPyliLQa svuwqkn8xIOlSmDOz+QVF8D4gylWi+Z6eFIhb4tL3jlnlHwjnr1sbWldOR3Pv6p5 pQSEddqXtccKkufMs6du/p/hexgK51arBK0gQZOUUSxPx0MWlvx1rqy/y8+cfIlm FkjwNAC8490irpGGT9K/AuSbm5lg19PzUofjLpUPAVxtBbrCeEkZHWcC0lTdoQ7R LSOn+GYORX7nOZG0wc0b5gAhq2nR6o5uORq6MuVJRXKkEt02t+wZItQTUERSw+wl VB6TaWVyB1kULQLbOMzi =Oo19 -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-23500-1395925304-0001-2-- From nobody Thu Mar 27 06:12:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F081A06A8 for ; Thu, 27 Mar 2014 06:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReLLwxQTOORp for ; Thu, 27 Mar 2014 06:12:30 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAF11A02A9 for ; Thu, 27 Mar 2014 06:12:30 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 674061A00B5; Thu, 27 Mar 2014 14:12:27 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RDjxcnpLSKIf; Thu, 27 Mar 2014 14:12:25 +0100 (CET) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id 0DD591A00B3; Thu, 27 Mar 2014 14:12:18 +0100 (CET) Received: from [10.53.40.204] (port=41970 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1WT9yy-0002S1-7y; Thu, 27 Mar 2014 14:04:32 +0100 Received: from [10.208.1.57] (10.208.1.57) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 27 Mar 2014 14:12:17 +0100 Message-ID: <533423B0.3030106@secunet.com> Date: Thu, 27 Mar 2014 14:12:16 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Alyssa Rowan , References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <20140327115551.GA24503@randombit.net> <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> In-Reply-To: <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.57] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Y9FIDgziFloQWTRVo9k7nTQBz4M Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 13:12:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Alyssa Rowan schrieb am 27.03.2014 13:27: > Suggestion: remove static RSA *and* traditional DHE and mandate ECDHE for key exchange in TLS 1.3. I propose, > curve25519 as mandatory-to-implement and secp256r1 as recommended-to-implement [? Also mandatory, maybe?], both in > constant time, which is comparatively easy, especially for 25519. It is not wise to base the security of a protocol on a single computational problem and fixed key length. - -- Johannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlM0I7AACgkQj8m9YkYyZmWTOACgxN3z0lnDf4vl6qaJOQHA/D4O q8EAnRhC2Dd2lgB5oAjXWNDeOZl8c5G0 =0+gV -----END PGP SIGNATURE----- From nobody Thu Mar 27 06:14:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426941A06EE for ; Thu, 27 Mar 2014 06:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 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, 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 AB6Lj_bvegTq for ; Thu, 27 Mar 2014 06:14:07 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 166FA1A0055 for ; Thu, 27 Mar 2014 06:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=offspark.com; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:To:From; bh=jYcTQ1hrsP9e6bt1gkVTYb9+C96Ecqw+ehXZAE1H9mY=; b=UP/NTMfUhSPNiyNrpCN8N2VRX1capQowsa3WC1egrn5PDzNOMktLnoASjVFa4QzLK7Mzg0hxXh+OcQ5Z6KptFVW+MPXkRMI5vTiB0/pj0W6LSmvrHP9mRR3ZIpEyi4arfPUJDDLh0IfbtPDeFvpkx4KWWUofmdjvz6m9FSWFCgg=; Received: from a82-161-132-220.adsl.xs4all.nl ([82.161.132.220] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WTA82-0005ZN-56; Thu, 27 Mar 2014 14:13:56 +0100 From: "Paul Bakker" To: "'Alyssa Rowan'" , References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <20140327115551.GA24503@randombit.net> <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> <02c101cf49b9$5d080da0$171828e0$@offspark.com> <3d2bb399-b932-4bc1-89d0-848260e0036d@email.android.com> In-Reply-To: <3d2bb399-b932-4bc1-89d0-848260e0036d@email.android.com> Date: Thu, 27 Mar 2014 14:13:51 +0100 Message-ID: <02e401cf49be$698ff650$3cafe2f0$@offspark.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFCyZKiN8ZEGaLHNGhiDtIsYJ3IqQINCKjVAjGxmm8CObuRPQI27pteAt/6p9AAgmRGqZutWZjA Content-Language: nl X-SA-Exim-Connect-IP: 82.161.132.220 X-SA-Exim-Mail-From: p.j.bakker@offspark.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pXSvq0vVaejSFRlL-0llrHbNwTY Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 13:14:08 -0000 > Maybe, if you're that constrained, you don't *really* want TLS and its x.509 > luggage at all: AES-GCM or ChaCha20-Poly1305 and a monotonic counter > nonce? And if you want forward security, and you probably should, then you > probably want... curve25519. I don't think my advice to those developers would be to 'invent' their own security channels. Most of them don't have the experience to do it right. And they're bound to make mistakes that have been fixed or mitigated in TLS. TLS as a whole is low-footprint enough with the right conditions. Of course, the pure PSK suite does not have X.509 luggage. But that's beside the point. And most developers don't have a choice. While I agree that some could better do something else, certain standards and / or certifications require usage of TLS. > I certainly don't see how that's a good argument for keeping DHE around, > which is the fattest of the key exchanges. Seems rather like the opposite, > actually. I never said we should keep DHE around! Just that we should not mandate a single other key exchange mechanism. I agree that DHE is fat and is not the best of the available choices. But things like PSK and PAKE-based key exchanges have their merits as well.. Paul Bakker From nobody Thu Mar 27 06:17:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840AD1A06B9 for ; Thu, 27 Mar 2014 06:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.612 X-Spam-Level: X-Spam-Status: No, score=-4.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07z4V7HaNyrT for ; Thu, 27 Mar 2014 06:17:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id D059E1A0055 for ; Thu, 27 Mar 2014 06:17:50 -0700 (PDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2RDHlK4022500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Mar 2014 09:17:47 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s2RDHiLh024181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 27 Mar 2014 09:17:46 -0400 Message-ID: <1395926264.19721.25.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Alyssa Rowan Date: Thu, 27 Mar 2014 14:17:44 +0100 In-Reply-To: <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <20140327115551.GA24503@randombit.net> <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aNdHPnwdYZcvyZsaeGc_FZcj-UQ Cc: tls@ietf.org Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 13:17:52 -0000 On Thu, 2014-03-27 at 12:27 +0000, Alyssa Rowan wrote: > On Thu, Mar 27, 2014 at 09:55:27AM +0100, Hanno Böck wrote: > > Appart from the other issues, I think it would make a lot of sense to > > change DHE handling in TLS 1.3 away from "server can have arbitrary > > parameters". > > I'm wondering: why even keep DHE around at all? Agility. I agree the DHE ciphersuites are problematic in TLS, but we also need agility. A cryptographic advance in elliptic curves may not translate to an advance in the "traditional" mod p fields, and in that case it would be nice having fallback ciphersuites, rather than suffer the issues of a monoculture. Nevertheless, I find discussions on such details fruitless at this point. I agree with Trevor that first it has to be discussed what process will be followed in the TLS 1.3 process. From the current discussions in the list it feels that TLS 1.3 will be 1.2 minus some features. regards, Nikos From nobody Thu Mar 27 07:16:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038841A0726 for ; Thu, 27 Mar 2014 07:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8vO-OJvWdnc for ; Thu, 27 Mar 2014 07:16:00 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id BA9391A0721 for ; Thu, 27 Mar 2014 07:16:00 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 84E1128502; Thu, 27 Mar 2014 14:15:58 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 736FB284E8; Thu, 27 Mar 2014 14:15:58 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 6EBE28005D; Thu, 27 Mar 2014 14:15:58 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Thu, 27 Mar 2014 10:15:58 -0400 From: "Salz, Rich" To: Alyssa Rowan , "tls@ietf.org" Date: Thu, 27 Mar 2014 10:15:57 -0400 Thread-Topic: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 Thread-Index: Ac9Jt/2CkHXbCzLvQ0S/ATLH80NmXgADswLw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE390@USMBX1.msg.corp.akamai.com> References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <20140327115551.GA24503@randombit.net> <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> In-Reply-To: <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Fia2MerINeki-xrhnQkTkxWozt0 Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 14:16:02 -0000 PiBJJ20gd29uZGVyaW5nOiB3aHkgZXZlbiBrZWVwIERIRSBhcm91bmQgYXQgYWxsPw0KDQpEb24n dCBwdXQgYWxsIHlvdXIgZWdncyBpbiBvbmUgYmFza2V0Lg0KDQo+IGVzcGVjaWFsbHkgY3VydmUy NTUxOSAod2hpY2ggd2UgaGF2ZSBhIGxpdmUgZHJhZnQgZm9yIG5vdw0KDQpJIHJlYWxseSBsaWtl IEN1cnZlMjU1MTksIGJ1dCB0aGUgY3VycmVudCBkcmFmdCBpcyBzdWItb3B0aW1hbCBpbiBob3cg aXQgc3BlY2lmaWVzIHRoZSBlbmNvZGluZy4gSWYgd2Ugd2FudCB0aGUgY3VydmUgZm9yIGl0cyBw ZXJmb3JtYW5jZSBnYWlucywgdGhlbiB3ZSBzaG91bGQgZW5jb2RlIHRoaW5ncyB1c2luZyBpdHMg bmF0aXZlLCAibW9zdCBuYXR1cmFsIiBmb3JtYXQuIEZpeGluZyB0aGF0IHJlcXVpcmVzIGEgY3Vy dmUgcmVnaXN0cnksIGV0Yy4gIEhvcGVmdWxseSB0aGUgQ0ZSRyBvciB0aGUgU2VjdXJpdHkgQUQn cyB3aWxsIGhlbHAgd2l0aCB0aGF0Lg0KDQoJL3IkDQoNCi0tICANClByaW5jaXBhbCBTZWN1cml0 eSBFbmdpbmVlcg0KQWthbWFpIFRlY2hub2xvZ3kNCkNhbWJyaWRnZSwgTUENCg0K From nobody Thu Mar 27 07:59:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2DC1A0745 for ; Thu, 27 Mar 2014 07:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 qtGfR1y7-Mfc for ; Thu, 27 Mar 2014 07:59:13 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id EF0031A0754 for ; Thu, 27 Mar 2014 07:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1669; q=dns/txt; s=iport; t=1395932349; x=1397141949; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iRMvjTamujIDgWcSKkyfVN2ivHkeo3pIO7gg6x45sxE=; b=iSYrbdypOVI45uignXmpQuTD4qnfOYZ7g5F+tghK7nkuadqLaXhpnWU5 b3wgYFhdDzCcM7PsvL+TXHG6HLMyxYiWaIyzZHuN1zXASGdGXGMhXlK2k T0WTTzvm9EtibkeXdvWo/YsISyPuZfIkY549yPos4ObTNcc9Z77zZKJDw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAAE8NFOtJV2a/2dsb2JhbABZgwaBEsJggRsWdIIlAQEBAwE6PwULAgEIGB4QMiUCBA4Fh3EI0Q8XjkAzB4MkgRQBA5hNkjSDLoIr X-IronPort-AV: E=Sophos;i="4.97,743,1389744000"; d="scan'208";a="313105975" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 27 Mar 2014 14:59:09 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2REx8oq024841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Mar 2014 14:59:08 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.247]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Thu, 27 Mar 2014 09:59:08 -0500 From: "Joseph Salowey (jsalowey)" To: Russ Housley Thread-Topic: [TLS] Confirming Consensus on supporting only AEAD ciphers Thread-Index: AQHPSSM6qiIeFUDRHUase0LCUT6SLpr0zi+AgACNkQA= Date: Thu, 27 Mar 2014 14:59:07 +0000 Message-ID: References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <3EAC453F-7902-48FC-B255-4416F50BBF82@vigilsec.com> In-Reply-To: <3EAC453F-7902-48FC-B255-4416F50BBF82@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.91] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zOs1Z6sD-NRzFsKmdNAbXyZGLCw Cc: "" Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 14:59:20 -0000 On Mar 26, 2014, at 11:32 PM, Russ Housley wrote: > I'd like to ask a clarifying question. >=20 > Please look at RFC 6476. In that document, Peter Gutmann uses traditiona= l encryption and integrity functions to make an AEAD cipher. Does this dec= ision allow or prohibit such ciphers? >=20 [Joe] The AEAD specification is TLS 1.2 is built from RFC 5116. This does= not restrict the type of algorithms used to build the AEAD cipher as long= as the result meets RFC 5116. I'm not sure that RFC 6476 can be used di= rectly, but you should be able to build an AEAD cipher out of the same algo= rithms. =20 Is your concern using RFC 6476 exactly or just being able to build a TLS co= mpliant AEAD mode out of traditional functions? > Russ >=20 >=20 > On Mar 26, 2014, at 2:43 PM, Joseph Salowey (jsalowey) wrote: >=20 >> TLS has supported a number of different cipher types for protecting the = record layer. In TLS 1.3 these include Stream Cipher, CBC Block Cipher an= d AEAD Cipher. The construction of the CBC mode within TLS has been shown = to be flawed and stream ciphers are not generally applicable to DTLS. Using= a single mechanism for cryptographic transforms would make security analys= is easier. AEAD ciphers can be constructed from stream ciphers and block = ciphers and are defined as protocol independent transforms. The consensus = in the room at IETF-89 was to only support AEAD ciphers in TLS 1.3. If you = have concerns about this decision please respond on the TLS list by April 1= 1, 2014. >>=20 >> Thanks, >>=20 >> Joe >> [Speaking for the TLS chairs] >>=20 >=20 From nobody Thu Mar 27 08:21:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFB31A06FB for ; Thu, 27 Mar 2014 08:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9_vrhPZ2ovS for ; Thu, 27 Mar 2014 08:21:41 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C05061A06F3 for ; Thu, 27 Mar 2014 08:21:41 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id t59so3770953yho.1 for ; Thu, 27 Mar 2014 08:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RboWv+f29uhFZUxx8gX5Bxw+yjavFko+SflVAZWPzf4=; b=h+miTv07b65QKY9yZlRv5mx8wl8/Qy7fZtbdoL6vDsyi+khTbE4butCVkuconWgDW9 l1fVp1B4kvMHoHFLnRaAr/2/MT5b42gmvtdFp3PunNMwp0Uj/UEoLmz1huPOTHN+W+ID ixQmzyLgTH2m4wIhmEx0r70Z+GtW1rM5DRJGAauTlwL4/Jm67mlnDKDpxahDFM/MylyV cp4S0IRM87Svh32zleJwku4frAUVGO9rOZdBNOqRJ/rIs+qtD/4Dm9oh2RGU6r8iR6Ax Jk6qtQo0XmQvM/AYJb9MiIX8M4ilEMENXVwg6Ns7iUj/r1Kp4YVOTd2IHCSrTDrvOIZI kqCQ== MIME-Version: 1.0 X-Received: by 10.236.139.70 with SMTP id b46mr3182254yhj.63.1395933699927; Thu, 27 Mar 2014 08:21:39 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Thu, 27 Mar 2014 08:21:39 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE390@USMBX1.msg.corp.akamai.com> References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <20140327115551.GA24503@randombit.net> <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE390@USMBX1.msg.corp.akamai.com> Date: Thu, 27 Mar 2014 11:21:39 -0400 Message-ID: From: Watson Ladd To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2TDFCmy6T5pgOybvXSwOWSD_CcI Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 15:21:43 -0000 On Thu, Mar 27, 2014 at 10:15 AM, Salz, Rich wrote: >> I'm wondering: why even keep DHE around at all? > > Don't put all your eggs in one basket. This is a good argument for preserving DHE. However, we lose everything when quantum computers come out. NTRU or McElise modes would be better backups. > >> especially curve25519 (which we have a live draft for now > > I really like Curve25519, but the current draft is sub-optimal in how it = specifies the encoding. If we want the curve for its performance gains, the= n we should encode things using its native, "most natural" format. Fixing t= hat requires a curve registry, etc. Hopefully the CFRG or the Security AD'= s will help with that. Integers have no natural encoding: you're complaining that one particular fast implementation encodes them a certain way. As for the registry etc, there are plans, but they have stalled admit rampant fence painting. I'll resubmit the safecurves draft and see if that gets things going again. Sincerely, Watson Ladd > > /r$ > > -- > 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 nobody Thu Mar 27 08:34:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6C41A0147 for ; Thu, 27 Mar 2014 08:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxCV28oECDfB for ; Thu, 27 Mar 2014 08:34:25 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id BA6C61A0270 for ; Thu, 27 Mar 2014 08:34:25 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5ABB7286AC; Thu, 27 Mar 2014 15:34:23 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 459482855A; Thu, 27 Mar 2014 15:34:23 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 3C672FE222; Thu, 27 Mar 2014 15:34:23 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Thu, 27 Mar 2014 11:34:17 -0400 From: "Salz, Rich" To: Watson Ladd Date: Thu, 27 Mar 2014 11:34:17 -0400 Thread-Topic: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 Thread-Index: Ac9J0EH4BqYBddUQQ9uiq+hKo9SRHQAAZ45g Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE42C@USMBX1.msg.corp.akamai.com> References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <20140327115551.GA24503@randombit.net> <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE390@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NUcLDSggJWQCGAQhTax0L3Mix2w Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 15:34:27 -0000 PiBJbnRlZ2VycyBoYXZlIG5vIG5hdHVyYWwgZW5jb2Rpbmc6IHlvdSdyZSBjb21wbGFpbmluZyB0 aGF0IG9uZSBwYXJ0aWN1bGFyIGZhc3QgaW1wbGVtZW50YXRpb24gZW5jb2RlcyB0aGVtIGEgY2Vy dGFpbiB3YXkuDQoNCklmIHRoZXkgaGF2ZSBubyBuYXR1cmFsIGVuY29kaW5nLCB0aGVuIGl0IG1h a2VzIHNlbnNlIHRvIHVzZSB0aGUgZW5jb2RpbmcgaW4gdGhlIHJlZmVyZW5jZSBpbXBsZW1lbnRh dGlvbiBkZXZlbG9wZWQgYnkgdGhlIGN1cnZlJ3MgaW52ZW50b3IuICBObz8NCg0KCS9yJA0KDQot LSAgDQpQcmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXINCkFrYW1haSBUZWNobm9sb2d5DQpDYW1i cmlkZ2UsIE1BDQoNCg== From nobody Thu Mar 27 10:51:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276F71A071A for ; Thu, 27 Mar 2014 10:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GUfMG3_x7Ms for ; Thu, 27 Mar 2014 10:51:52 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD9A1A0718 for ; Thu, 27 Mar 2014 10:51:52 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 200so2648726ykr.17 for ; Thu, 27 Mar 2014 10:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2VygmRhlmDJG/YqQo9FR4mUyYI0T5cmHptseHJZnaOk=; b=StQVgG2YvXlxf6im5/9elRFtMixAnea0w70pBCa07b0Jk3OIUKfBmlEPBLlX7GzBsq X50lMOqwWdywGvuxz1naeDZ0UG1p/0X0Y5KjSMfWcwMz0Qrqoi2mrHZQGIqJlR3BT6ik eNNnGrQS2IQtU5cnyVDg9pdFMeEipuTFknWQS0dKPceJlRCfLrB63acE3bQoef6a78xC l9OfMydYcfdBkna41U3zSNXUyDk01oKJNP8vuXl/CWm3l2V9kwnVnKUxrDFvK/Ffu/HP YpTBda8vwh2dQTliYH/GfuBKwf8fRZAjNfkGZSU3o5o89ccJCUOddzKMRJfApcC9BalF SVVw== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr4310033yhi.4.1395942710714; Thu, 27 Mar 2014 10:51:50 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Thu, 27 Mar 2014 10:51:50 -0700 (PDT) Date: Thu, 27 Mar 2014 13:51:50 -0400 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/J8MZgQOfLvKaknR-6R8P-J6QVpM Subject: [TLS] TLS 1.3 process and consensus X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Mar 2014 17:51:54 -0000 Dear all, I cannot count myself as among the supporters of the consensus calls that the leadership has recently issued for a very simple reason: TLS 1.3 does not exist, and therefore to consider the consequences of changes to it is impossible. As good as the ideas are, to judge features in isolation is to end up with a Baroque monstrosity. Behind such pedantry is a serious point: TLS 1.3 has quietly become TLS 1.2 with some features removed, and maybe a few new flows. As such, the final product will be heavily influenced by design decisions inherent in the choice of direction the TLS WG leadership has made, with very little discussion from the membership about these choices. None of us has the knowledge of the TLS ecosystem to design an acceptable solution individually. I think we should try to understand the design space for TLS 1.3 in greater detail by enlarging the number of proposals under consideration before we commit to a process of local optimizations. Even more clarity from the WG chairs on the process would be welcome. SIncerely, Watson Ladd From nobody Thu Mar 27 12:13:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C9C1A037E for ; Thu, 27 Mar 2014 12:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEodAS9Fbpgv for ; Thu, 27 Mar 2014 12:13:36 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DB9641A0303 for ; Thu, 27 Mar 2014 12:13:35 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id D898EF984 for ; Thu, 27 Mar 2014 15:13:32 -0400 (EDT) Message-ID: <53347850.20000@fifthhorseman.net> Date: Thu, 27 Mar 2014 15:13:20 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: "tls@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DpTBFG4jQiQA3tJ2uLba4U3gbc0XlUJmp" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/b38-jRDQR7HG0m2TeXUFoH6dy08 Subject: Re: [TLS] TLS 1.3 process and consensus X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Mar 2014 19:13:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DpTBFG4jQiQA3tJ2uLba4U3gbc0XlUJmp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/27/2014 01:51 PM, Watson Ladd wrote: > I think we should try to understand the design space for TLS 1.3 in > greater detail by enlarging the number of proposals under > consideration before we commit to a process of local optimizations. > Even more clarity from the WG chairs on the process would be welcome. I think some gathering of general opinon is a good idea, as long as it's clear that we're establishing metrics by which we might judge a future implementation and not absolute requirements. Some of the things that people generally want could come into conflict, and then proposals about what the future TLS 1.3 would be will be assessed by how well they meet the various, possibly-conflicting goals. I note that we don't appear to even *have* full consensus on any of the proposals raised thus far: all-PFS, no-Compression, all-AEAD, though i get the general sense that most people are OK with each of them. Likewise, we have some rough goals for TLS 1.3 as expressed in the charter, like minimizing round trips and keeping as much of the handshake encrypted as possible. I'd be happy to see us try to add some sort of resistance to traffic analysis as a goal as well, though i recognize that there are bandwidth and latency and computation concerns there. And while i'm listing my ponies, I'd also like to see us end up with a spec that is amenable to theoretical security proofs based on reasonable models of known attacker capabilities. But if gathering the sense of the group on these points means that we've painted the process into a corner whereby no proposal (however good) that doesn't meet condition X will possibly be considered, then i think we've done the WG (and the community that relies on it) a disservice. We should be gathering these goals as metrics to measure a complete proposal against, not as a strict litmus test or as a way to cobble something together. That said, it's possible that there are some absolute WG constraints for a future TLS 1.3. For example, we might require that the TLS 1.3 initial handshake stage be backward-compatible with earlier TLS handshakes, so that it can be run over the same port as TLS 1.2 without conflict for those servers and clients that choose to implement multiple versions of TLS. (Can this constraint be phrased more precisely so proposals can verify their compliance with it?) This constraint seems guaranteed to hobble any more radical designs (for example, i think it rules out any server-speaks-first protocol), but may be the only realistic outcome in the context of this WG; otherwise people could just refocus their work on entirely different protocols (e.g. QUIC). I think we would do well to explicitly state any hard requirements we actually have, alongside any articulable goals, and then encourage people to submit full protocol specifications for the group to review against these requirements and goals. Those specifications might change between revisions, and maybe a new spec will arise that uses good ideas from other specs; but assembling the full spec piecemeal from the beginning seems like a way to end up with the kind of patchwork that has bitten us several times in the last several years. So, are these things Requirement, Goal, Dont-Care, or Do-Not-Want? from my perspective: Handshake-Interop-with-TLS-1.{0,1,2}: Requirement All-PFS: Goal Avoid-Compression: Goal All-AEAD: (i think this is too unclear to say, see Russ' question) 0-RTT-Capable: Goal Minimize-Latency: Goal Traffic-Analysis-Countermeasures: Goal Theoretically-evaluable: Goal Encrypted-Handshake: Goal Algorithm-Agility: Goal I'm sure there are other axes of the design space that i'm not listing here. I'd love to see people make concrete proposals for TLS 1.3 that we could evaluate against them, even if they can't succeed on all fronts.= --dkg --DpTBFG4jQiQA3tJ2uLba4U3gbc0XlUJmp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTNHhQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcWCkP/3bP3hGs/gm+OaCtbibumzNh 4mC7QBWeJLjbVJ8VWxjMxVc0Af8aihYpDB2rRZx40EQfWj5Hi3bLH3vSr767Ug3w a72xgPnvgv3/HjtmoNZs8G6Qnmr7hqj2Dtrwa8W8ep+5Obrz0CLGKtR7sEwLWEfL YiqJr2PKbBuIVAhRLeD7yhIpUV7YEeSqHqVmqeZqNyLIbU6djz6Ds5Ls4ZjNmldT Ys8uwlsm0T6rx2vlQzDTIqT9gXdFtkyTBM108Sq4B7l6czoyySOMoMoWlaoq/EOE Ujp8gV4iTZLkWcZnPW2k6JZbiuoeuj1Yx/IxaUJdI7pv3ieoE84jDtG7YvCOTSF1 Z0BsXaG4Nxj/G5M7yOLofwh+uRc3mpAx+cB9gzlaylr/DU6PCtpEHZRy9+mh16x5 v4D5ZwfNmDZsfcKlcJm6/b39wqaE/2i5Tpz5I0a8WlB6muuBL3AWYie1UdXe5mzD u0KeDek4QqYuwPuRg16VSYMYO5IUnQptj55A3e9ajxHD7iOAQQBYDtKBwYQWiszl iGm2HkbQacJa6fCta4lKOHZnOlW8nq9c2teHGoiGekvtnVXRitNqpsXH7b/iX8PD mBzSF3BLeVest+bbCQf4uikxxbCtFNRQJy1yXNph2C1T4ab2X9hvms0V9fRuLnx6 om2u5BmUfKfJeOtAttgW =/GOW -----END PGP SIGNATURE----- --DpTBFG4jQiQA3tJ2uLba4U3gbc0XlUJmp-- From nobody Thu Mar 27 14:49:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A781A06A8 for ; Thu, 27 Mar 2014 14:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 GYczCBbxGD9A for ; Thu, 27 Mar 2014 14:48:55 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [70.85.67.23]) by ietfa.amsl.com (Postfix) with ESMTP id 67B3C1A06E1 for ; Thu, 27 Mar 2014 14:48:55 -0700 (PDT) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 7BFA3FF0D60C9; Thu, 27 Mar 2014 16:48:53 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 567AAFF0D6061 for ; Thu, 27 Mar 2014 16:48:53 -0500 (CDT) Received: from [96.231.225.192] (port=52401 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1WTIAO-0005Ux-Qf for tls@ietf.org; Thu, 27 Mar 2014 16:48:52 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Thu, 27 Mar 2014 17:48:47 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.4]) [96.231.225.192]:52401 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 10 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rTlVyrn2Rdf4yEf9cn8OH77x1Dw Subject: [TLS] TLS 1.3 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: Thu, 27 Mar 2014 21:48:58 -0000 All, The TLS WG charter is pretty clear that the intention isn't to design a completely new protocol but rather to revise TLS, and specifically to "place a priority in minimizing gratuitous changes to TLS." This is not to say that we can't consider new cryptographic handshake flows -- TLS has always been open to that -- but completely replacing TLS with a new protocol is out of scope for this WG. With this in mind and regard to the bigger question about the process, here's how the chairs intend to proceed: 1. Start with the existing TLS document. As usual in IETF, this doesn't mean that any particular piece of the document cannot be changed if the WG wants to, but it's where we will start; it also makes it a lot easier to get through the process since the IESG, directorates, and WGs that depend on TLS can see what changed. 2. If possible, remove the pieces we agree we don't need (hence the recent consensus calls). 3. Settle on the high-level handshake flows (charter items #1 and #2) in light of #2. 4. Reevaluate the handshake PDUs (charter item #4) 5. Update record protection mechanisms in the record layer (charter items #3 and #5) 6. Iterate on the document until complete. Key to this process is getting input from academic cryptographers, which is why we are prioritizing the handshake flows, because they are probably the piece that needs the most analysis. 7. Publish. With that said, the reason for the present consensus calls should be clear, as they are intended to either remove pieces (#2) or resolve requirements for the handshake (#3). To sum up: We have a set of requirements, from the charter and from the consensus calls we're having now. Our chartered goal is to meet those requirements with the minimum set of changes to TLS. TLS co-chairs j & e & s From nobody Thu Mar 27 15:02:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741FE1A06B2 for ; Thu, 27 Mar 2014 15:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lBYtMXBpiCtk for ; Thu, 27 Mar 2014 15:02:02 -0700 (PDT) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD761A03DA for ; Thu, 27 Mar 2014 15:02:02 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id y10so3984011pdj.27 for ; Thu, 27 Mar 2014 15:02:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ueTwsP65WlWPP5vMRdsOal3/XGrOGjXOjXPXLuCGk6E=; b=jiGi9oJQs5JwIMm3p3+uv0gBKv+0/Z3G46W7qOUet4Spb8ULHoRKSKWj3SZVogqiRd fArMcLnnCDLeyNKfy95BPbYI9k/fzBAXrUJ0vTF5V0q44KSsbRov/PpzEx1u2UIuTh9o rHo1BshNRMRJLKkOvyLSDhVoCO6J1arFxDFa6ViZ8Vrx76PSbW8le9DW6/CqblgTpc9+ 1tzuwc8RKUSJ6STWzTqzbQDjhglISpzS+7jqLKqEt0CtG6veY9M928Os5xtmxL13zyv+ r3uR/Zi/SVKwJtzskh+xcDjJb8Xhgux9XCCt+cT+QuF8/mndwsrrnlJHdUsaeJhlh2lI 58FQ== X-Gm-Message-State: ALoCoQm+RQXCOyMpw9RbMzGFEBCQz5pfL3tSeBaieHxMfbciw7hZz/TGTuzTP/AYw8cxkV2GL84a X-Received: by 10.66.21.7 with SMTP id r7mr4354819pae.135.1395957720456; Thu, 27 Mar 2014 15:02:00 -0700 (PDT) Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id iu10sm13755973pbd.71.2014.03.27.15.01.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Mar 2014 15:01:59 -0700 (PDT) Message-ID: <53349FD6.8070909@mit.edu> Date: Thu, 27 Mar 2014 15:01:58 -0700 From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tls@ietf.org References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <20140327115551.GA24503@randombit.net> <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> <20140327140100.0b98c4b5@hboeck.de> In-Reply-To: <20140327140100.0b98c4b5@hboeck.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KCIhajSQHVZTapqr0TvDnnFRBck Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 22:02:04 -0000 On 03/27/2014 06:01 AM, Hanno Bck wrote: > On Thu, 27 Mar 2014 12:27:17 +0000 > It will be easier to build a quantum computer to break 512 bit keys > than one to break 4096 bit keys. That's why in a word where quantum > computers become a reality I'd rather go with RSA+DHE with large > key/modulus than with anything from the ECC family. Barely. With my quantum cryptography hat on, I think this is a pointless thing to design in. If you can build a big enough quantum computer to run any of the period-finding / hidden subgroup algorithms, then it seems extremely likely that you have a real fault-tolerant machine with a real memory interconnect. At that point, the machine size scales pretty much linearly with the size of the group. It's a bit different if the attacker has an adiabatic machine, but I'd be absolutely shocked if the first machine to run Shor's algorithm is adiabatic. --Andy From nobody Thu Mar 27 15:46:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC60D1A024E for ; Thu, 27 Mar 2014 15:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozGveRcyy4fu for ; Thu, 27 Mar 2014 15:45:58 -0700 (PDT) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id E5B9C1A06F0 for ; Thu, 27 Mar 2014 15:45:57 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id fp1so3997941pdb.28 for ; Thu, 27 Mar 2014 15:45:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZxKhvEk4If5Vnu2MuIdbJgBVoe7hjlUP/CuBrI2+/+c=; b=PF0JPwEfGVkYQocXkBHVdvnQ/y8fJZIwY2Clgbna7NHxy5Hqn8lEGtG6YLlhpTcC/5 tCUtiGrrnKkF1U2aK/luLfkLvLFiLTV1wXlQJbgECnNXwAwx4DL5VJi3T2M9qwMO42Fa QEYsEVTqAcs7znhV7tJpymSLsQW1wpHSCPadBmR/SYd5OyMlkhzHcQC3ktEAaJV7FvbK 01/PA3Qy7rhCZH0BywQ6KFIfCwLfAly8aW3tsHNPKzWLDkk+JFJYT0RqVPjUZdCAbrwD klWSCr8EDqof8a+CHyV46JlKhy8KfVyOkU5yu6ktuxVSlr5MwPVskVyuwmeJEelJZngh zTUg== X-Gm-Message-State: ALoCoQljBv7o1VNJ6j6voy5xp8/RhaYj4OWbvlpKw91T+60/P0lTeuxsTeXLgLnoBNcvf0i0hcLl MIME-Version: 1.0 X-Received: by 10.66.192.162 with SMTP id hh2mr4536463pac.150.1395960356145; Thu, 27 Mar 2014 15:45:56 -0700 (PDT) Received: by 10.70.84.196 with HTTP; Thu, 27 Mar 2014 15:45:56 -0700 (PDT) X-Originating-IP: [184.23.29.222] In-Reply-To: References: Date: Thu, 27 Mar 2014 15:45:56 -0700 Message-ID: From: Trevor Perrin To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HV-46xMe-gWCf4brLA4czfiGI5Y Cc: "" Subject: Re: [TLS] TLS 1.3 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: Thu, 27 Mar 2014 22:46:00 -0000 On Thu, Mar 27, 2014 at 2:48 PM, Sean Turner wrote: > All, > > The TLS WG charter is pretty clear that the intention isn't to design > a completely new protocol but rather to revise TLS, and specifically > to "place a priority in minimizing gratuitous changes to TLS." This > is not to say that we can't consider new cryptographic handshake flows > -- TLS has always been open to that -- but completely replacing TLS > with a new protocol is out of scope for this WG. Hi Sean, Thanks for creating this discussion. The distinction between a "new protocol" (forbidden!) and re-evaluating / updating both the handshake and record layer is not super clear to me. For example: Eric's draft redesigns the TLS handshake around the new concept of "semi-static public keys". That gave me the impression we're willing to consider radical changes! Is that not the case? I also didn't expect such a strict interpretation of the charter, and such a rigid process. Your email in January gave a different impression: """ Rene, A couple of people have mentioned the fact that list of objectives is incomplete or they're worried their issue not being listed means it's out of scope. Right now the charter includes the following to address this (at least in my mind) "Some of the main design goals are as follows, in no particular order:" That list is honestly there to make sure the IESG will be comfortable agreeing to the rechartering. What I hope will happen is that folks can bring their proposals, they get evaluated, and the WG will use its better judgement about what makes sense to get adopted. """ http://www.ietf.org/mail-archive/web/tls/current/msg11257.html That email made it seem like we should not worry too much about the charter, we'd have time for "folks to bring their proposals" later. I would have asked for more clarity on the charter - and the "minimizing gratuitous changes" phrase - if not for that. Anyways, maybe this is just me. If everyone else understand what scope of changes is allowed, and is happy with the step-wise process you describe, then that's fine. I'm happy we're discussing this. But I would personally prefer a more open process based around soliciting and comparing different proposals, without pre-judging in advance what changes are "gratuitous". Trevor From nobody Thu Mar 27 15:56:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A3F1A0274 for ; Thu, 27 Mar 2014 15:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsPo1LrQiPmd for ; Thu, 27 Mar 2014 15:56:28 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4201A024E for ; Thu, 27 Mar 2014 15:56:28 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 142so102833ykq.41 for ; Thu, 27 Mar 2014 15:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=O+FFPqKXVxCcjjAvA619ptG0MkmmvaFPDBuu672g36Y=; b=PUcpg35T0lOntBmF6b9PiCFxv7SF2s0RBY8JR5ySE2x8qOCftLBP57zvEFmz5m0OCI maxVxvUtmD2i66iEvHd27AvVziAsumlV6gusD8NvXJZLgo8gHPKwxqqax5mtuHElEiX/ nzTugztwykOQBm0TQZ8w9dFBOsfe6v2GIgAGWMc3rtoqHko178AZubIQKNgqR+TYTJSs +HFI/C2jX2qAdIXx5yT935YMMm/AyXUCDl6wsR9V2vDogXj+TUJKKQNq6XwMozW26lU5 tEksVBCajQZsBZPTTFeFfiqJoYQWWi0fizDN6U52BqiHEssyARyXuZuQ7pZaN8Sr8M5w WsyA== MIME-Version: 1.0 X-Received: by 10.236.163.8 with SMTP id z8mr573043yhk.43.1395960986253; Thu, 27 Mar 2014 15:56:26 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Thu, 27 Mar 2014 15:56:26 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Mar 2014 18:56:26 -0400 Message-ID: From: Watson Ladd To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/g40g2wy6vD3InhhJSVDTk3lE92Y Cc: "" Subject: Re: [TLS] TLS 1.3 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: Thu, 27 Mar 2014 22:56:31 -0000 On Thu, Mar 27, 2014 at 5:48 PM, Sean Turner wrote: > All, > > The TLS WG charter is pretty clear that the intention isn't to design > a completely new protocol but rather to revise TLS, and specifically > to "place a priority in minimizing gratuitous changes to TLS." This > is not to say that we can't consider new cryptographic handshake flows > -- TLS has always been open to that -- but completely replacing TLS > with a new protocol is out of scope for this WG. > > With this in mind and regard to the bigger question about the > process, here's how the chairs intend to proceed: > > 1. Start with the existing TLS document. As usual in IETF, this > doesn't mean that any particular piece of the document cannot > be changed if the WG wants to, but it's where we will start; > it also makes it a lot easier to get through the process > since the IESG, directorates, and WGs that depend on TLS > can see what changed. > 2. If possible, remove the pieces we agree we don't need (hence the > recent consensus calls). > 3. Settle on the high-level handshake flows (charter items #1 and #2) > in light of #2. > 4. Reevaluate the handshake PDUs (charter item #4) > 5. Update record protection mechanisms in the record layer > (charter items #3 and #5) > 6. Iterate on the document until complete. Key to this process is > getting input from academic cryptographers, which is why we > are prioritizing the handshake flows, because they are probably > the piece that needs the most analysis. > 7. Publish. I don't think this will work out well for the following reasons. Firstly, the TLS spec is a mess. Necessary extensions aren't included, so if you want to use ECDHE, you need to go on a hunt for the proper specification. Likewise, if you want secure renegotiation, that gets incorporated by reference also. There isn't a clear model of what is supposed to happen in conforming implementations. Fixing this will require major editing. ECDHE encodings can't accommodate anything that isn't a short Weierstrass curve over a prime or binary field, which is causing trouble on curve25519. This sort of housekeeping isn't interesting, or rewarding. It is necessary to avoid the "Oh, well, this RFC you never heard off addresses the issue in the one you thought would be the right one to look at" problem. Secondly, the record layer issues are much worse than the handshake issues in TLS 1.2. There are good handshakes like ECDHE_RSA and ECDHE_ECDSA available today, with side-channel protected implementations on all platforms. That cannot be said for the record layer: AES-GCM only works on late Intel hardware without side channels, even with the K=C3=A4sper-Schwabe implementation. It would be desirable for any fix for this issue to work on TLS 1.2 as well. There are already drafts handling this, as well as work in UTA. Tying this work to a version number bump would be ridiculous. Thirdly, the handshake issues are much worse than the record layer issues in TLS 1.2. We understand what the record layer is supposed to do. We don't understand what the handshake is supposed to do: channel bindings got broken because they made assumptions that the handshake layer didn't in fact meet. In contrast we understand very well what the record layer is supposed to do, and why the existing options fail. I don't see people thinking about the interactions between 0-RTT, existing resumption, and channel binding. It could be quite fun. We still don't have anything concrete to critique or analyze here. Given all this, I would say the best thing to do is focus on the handshake while the committee does the record layer enhancements via enhancements to TLS 1.2, and have TLS 1.3 focus on the handshake fixes and enhancements that are required after that. Sincerely, Watson Ladd > > With that said, the reason for the present consensus calls should be > clear, as they are intended to either remove pieces (#2) or resolve > requirements for the handshake (#3). > > To sum up: We have a set of requirements, from the charter and > from the consensus calls we're having now. Our chartered goal is > to meet those requirements with the minimum set of changes to TLS. > > TLS co-chairs > > j & e & s > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Mar 27 16:06:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A301E1A0721 for ; Thu, 27 Mar 2014 16:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5j3rBjo7JVE for ; Thu, 27 Mar 2014 16:06:54 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3746B1A03DF for ; Thu, 27 Mar 2014 16:06:54 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id r20so121674wiv.15 for ; Thu, 27 Mar 2014 16:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6mJ+MNuMNBpaXVx1KHnPEN17ejnn/9w96qp2lNlDUQc=; b=Tb//xhBsHYIuC5sKhKL+RGaKJ9hWglDMBbcvl9Lzpp45ZTuI0nNXRubNR+QQvVCOk6 HbrsogVvwvP0vZulT5wNTFzrhLoT+27Xr4sL1aVyW/TOP7wrJ9x1bmnRGdVPBZZHflRu PmKf3D5qlfyd8MPlklz1hSVyQYOxbDjZ4Jkqp1WiBVy7Y47TxhejyZNTpm8z9VRxJnkL ntHbwwlnlVjXpXP+d5WSwv5w5gbA2bCi0VHx2R5fNdxxjW/ag09W22AHi98oDiZ7qMqs 7/HK7XNchxeJQqE5AJ3KPNesYPEecmVSE7nCHp2TiuiMt+4lPzpCk/GRJ2gJso1yphTK cLJw== MIME-Version: 1.0 X-Received: by 10.180.92.196 with SMTP id co4mr8398821wib.50.1395961611748; Thu, 27 Mar 2014 16:06:51 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Thu, 27 Mar 2014 16:06:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Mar 2014 16:06:51 -0700 Message-ID: From: Martin Thomson To: Trevor Perrin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vNO2NJOy8IIlH4o3DExuVG_Ft7A Cc: "" Subject: Re: [TLS] TLS 1.3 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: Thu, 27 Mar 2014 23:06:56 -0000 On 27 March 2014 15:45, Trevor Perrin wrote: > But I would personally prefer a more open process based around > soliciting and comparing different proposals, without pre-judging in > advance what changes are "gratuitous". I'll note two things here: 1. nothing leaves the working group until there is consensus for it to do so, no matter what process has been followed 2. nothing prevents you or anyone from making a proposal...at any time If it turns out that major surgery or even a complete rewrite is necessary, and there is working group consensus for either, then I have faith that someone will make that proposal. And that proposal, I hope, will be judged on its merits. So far, I haven't seen any evidence that what Sean describes is a bad plan. In fact, since our chairs have run this rodeo before, I have a strong suspicion that this is a decision based on experience with getting results. I would like results. From nobody Thu Mar 27 16:55:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A936B1A0743 for ; Thu, 27 Mar 2014 16:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m72UYJCxfBDn for ; Thu, 27 Mar 2014 16:55:45 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC811A073F for ; Thu, 27 Mar 2014 16:55:45 -0700 (PDT) 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.898.11; Thu, 27 Mar 2014 23:55:41 +0000 Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.88]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.88]) with mapi id 15.00.0898.005; Thu, 27 Mar 2014 23:55:40 +0000 From: Marsh Ray To: Alyssa Rowan , "tls@ietf.org" Thread-Topic: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 Thread-Index: AQHPSTgaoRbACzy1oE29DCWXv4AbFZr0oiiAgAAyZ4CAAAjIgIAAvjuQ Date: Thu, 27 Mar 2014 23:55:40 +0000 Message-ID: <6e87fc16e34941318c9fc336e88caea6@BY2PR03MB074.namprd03.prod.outlook.com> References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <20140327115551.GA24503@randombit.net> <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> In-Reply-To: <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> 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: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(51704005)(13464003)(50986001)(85306002)(47976001)(95416001)(4396001)(47736001)(49866001)(95666003)(85852003)(83072002)(93136001)(92566001)(98676001)(87266001)(87936001)(2656002)(90146001)(56816005)(79102001)(33646001)(77982001)(20776003)(63696002)(74366001)(59766001)(74706001)(74876001)(80022001)(46102001)(65816001)(77096001)(76576001)(76796001)(76786001)(76482001)(56776001)(54316002)(80976001)(53806001)(54356001)(19580405001)(19580395003)(83322001)(94316002)(86362001)(93516002)(94946001)(86612001)(81816001)(81686001)(51856001)(81542001)(74316001)(97186001)(97336001)(69226001)(81342001)(47446002)(31966008)(74502001)(74662001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB074; H:BY2PR03MB074.namprd03.prod.outlook.com; FPR:943DC737.2CFFEECA.EDDEBFBB.C4208B39.200D1; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Dz__AMgVjNJlpku9HE5HO71BU44 Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 23:55:46 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWx5c3NhIFJvd2FuDQo+DQo+IFNob3cgb2YgaGFuZHM6 IHdobyAqcmVhbGx5KiB3YW50cyB0byBkZXBsb3kgMjA0OC1iaXQgKG9yIGFib3ZlKSBESEUsIHdo ZW4gdGhleSBjb3VsZCBoYXZlIGN1cnZlMjU1MTkgaW5zdGVhZD8NCg0KVGhlIGdlbmVyYWwgY29u c2Vuc3VzIGF0IE1pY3Jvc29mdCBpcyB0aGF0IHdlIGxpa2UgRUNESEUgbXVjaCBiZXR0ZXIgdGhh biB0aGUgY2xhc3NpYyBESEUuDQoNCi0gTWFyc2gNCg0K From nobody Thu Mar 27 16:57:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06621A0743 for ; Thu, 27 Mar 2014 16:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRyGdhf07HUE for ; Thu, 27 Mar 2014 16:57:26 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id BF0D11A073F for ; Thu, 27 Mar 2014 16:57:25 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so168370wiv.3 for ; Thu, 27 Mar 2014 16:57:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ClrtDc4AG6hrJpo6EPFsIVmrtSET6cKM2QSNIhsTx08=; b=RQfg3BqUArRNoil2gqL6KqjHDw8TX2m5H1PgcDF56I8my9vW9U4uP3wGOn01WkfjI0 kaegom6Cy1A3QPq+DB/H//mzKb7SAJQdWc7zZeDUADKKCjww4OpMPkXBvMYd3LAL9w3Z njsYr3tp5ulUU7D5qw0uYBGgb/+wAgy1dWgx+DE3iZ7drrAbRnHt9FEewaYeaLtqJNiq C2ir3VL27meFSQf37IMGcqcg/o2tIR8Ero9/uVA+S0SvIhOdAMlQXMrIdDw0d0mopIDV NF69MgyMiefymNjRRy7oo8bwQ4WoQd/sb9Hdt5aX9MFu2SwMOutXsUTYzKGqejhcLjpx ps8A== X-Gm-Message-State: ALoCoQmN5M8w1otmmnN4gPtZxlIkTg9BBsGyAwQK4jcsVquuWMi3h/IKyz9eb0QKuWEjnzGREzui MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr43681974wib.39.1395964643229; Thu, 27 Mar 2014 16:57:23 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Thu, 27 Mar 2014 16:57:23 -0700 (PDT) X-Originating-IP: [184.23.29.222] In-Reply-To: References: Date: Thu, 27 Mar 2014 16:57:23 -0700 Message-ID: From: Trevor Perrin To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Muy0UixZuWrCs4BPQVXQTXLHtcE Cc: "" Subject: Re: [TLS] TLS 1.3 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: Thu, 27 Mar 2014 23:57:27 -0000 On Thu, Mar 27, 2014 at 4:06 PM, Martin Thomson wrote: > > 2. nothing prevents you or anyone from making a proposal...at any time Sure, here's my proposal: * The WG chairs continue to encourage discussion of goals and design alternatives for TLS 1.3. However, the WG holds off from making binding decisions regarding TLS 1.3. * The WG encourages interested parties to submit proposals for TLS 1.3. * In X months time (4-6?), the WG chooses which proposal to adopt as the base for TLS 1.3, and works to improve it for publication. Trevor From nobody Thu Mar 27 17:04:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16611A03F8 for ; Thu, 27 Mar 2014 17:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gexR1fTSY3T2 for ; Thu, 27 Mar 2014 17:04:04 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6F68E1A034E for ; Thu, 27 Mar 2014 17:04:04 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id n12so3102803wgh.24 for ; Thu, 27 Mar 2014 17:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=roF9RkhIXsn9ZF/APyMfwlLLcwgqbtuDO0j64z1vUFc=; b=mD/DoCwsQfw3ZKdVrcslY9m7YDPjo3BMVvCEgFnHyWJQMigXAkfPlUelBDaWB4riQw RU+UgHsoDGLPjRtUmTlSYL05+8Vr3E2gOJ91kWEY1Kd9UaH+OWOv39KQ5z5nT22yE7LL 5jwj4jy70nf4fmOlXhMZJEfCdUwYFFR7HKIKe/yKWDJ3oBRqOxZHphuIF7wLttXWjutG LaeJbiefiEYWeFoaC7+LDP7+nstyGN6SVYqYmJUiGyWlda5ixXOxYE1pc4xCI8pRXVoP QVXK62wRTiB8CTRw9eDVuhS2EpJA6OkPz1srOKCSDEkgePaN0gmH1zBvh3zYslKhfgNT r1yQ== MIME-Version: 1.0 X-Received: by 10.180.75.202 with SMTP id e10mr43825418wiw.50.1395965042034; Thu, 27 Mar 2014 17:04:02 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Thu, 27 Mar 2014 17:04:01 -0700 (PDT) Date: Thu, 27 Mar 2014 17:04:01 -0700 Message-ID: From: Martin Thomson To: Marsh Ray Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EE7wZDWyGYc7ehK5oyZGvTaHovE Cc: "tls@ietf.org" Subject: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 00:04:06 -0000 (Renaming the thread, since this is what we seem to be talking about) On 27 March 2014 16:55, Marsh Ray wrote: > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Alyssa Rowan >> >> Show of hands: who *really* wants to deploy 2048-bit (or above) DHE, when they could have curve25519 instead? > > The general consensus at Microsoft is that we like ECDHE much better than the classic DHE. I think that this is the general trend, but is it so bad that you would want to prohibit DHE? From nobody Thu Mar 27 17:09:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77DF1A03F8 for ; Thu, 27 Mar 2014 17:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcqgENc3eusy for ; Thu, 27 Mar 2014 17:09:06 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 283981A034E for ; Thu, 27 Mar 2014 17:09:06 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id v1so4369035yhn.40 for ; Thu, 27 Mar 2014 17:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=STgYRL3dWKbZyHl61epWk7Wo5c8sFsK6Iw1yAq0x+iM=; b=eFHh8DhdhVGmwOCIDQ4Be9KLdRGTvP4ILa94jzS/VrqU1ZGcYjbwJNcTSWva95awqd RfrCp8wDZPiWxEpTeV7Cc9HRXeKqNmq+7OKydUjwRayHmz4HwM0eYCOJvpcY/REQZdqk HYCoSxn3MMhmHeso0/4WCXNw6i7jXWbNce1XIJwhegehomAkhDzNWJ5xPWJma5UXWYTQ AEeP4ybuQBABvMQ7FBPiXeAT90Wmuk1lp+51KsERoQD66EvGMd9itrM0rJ4kMiVqcbb7 Z0HiTEr3jATdHACtk7PKgl4Kc06SLGFYc9g/QE2bZ/UwaRTQbk5+6YEl/cRt/UYnyEVL 0b+g== MIME-Version: 1.0 X-Received: by 10.236.44.173 with SMTP id n33mr6729564yhb.2.1395965344146; Thu, 27 Mar 2014 17:09:04 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Thu, 27 Mar 2014 17:09:04 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Mar 2014 20:09:04 -0400 Message-ID: From: Watson Ladd To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uDfuvwZRo-IsEYPPBQtrfUUJOGY Cc: "tls@ietf.org" Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 00:09:11 -0000 On Thu, Mar 27, 2014 at 8:04 PM, Martin Thomson wrote: > (Renaming the thread, since this is what we seem to be talking about) > > On 27 March 2014 16:55, Marsh Ray wrote: >> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Alyssa Rowan >>> >>> Show of hands: who *really* wants to deploy 2048-bit (or above) DHE, when they could have curve25519 instead? >> >> The general consensus at Microsoft is that we like ECDHE much better than the classic DHE. > > I think that this is the general trend, but is it so bad that you > would want to prohibit DHE? Well, the DHE handshake has validation issues: implementations aren't checking they get sensible inputs. Fix that, and maybe you have an argument for keeping it. But as it stands now the insecure resumption attacks are exploiting behavior in DHE that isn't fixable without a DOS vector being introduced. Sincerely, Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Mar 27 17:17:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1665D1A03F8 for ; Thu, 27 Mar 2014 17:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME9p8oBaMOBX for ; Thu, 27 Mar 2014 17:17:32 -0700 (PDT) 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 776771A01C6 for ; Thu, 27 Mar 2014 17:17:32 -0700 (PDT) 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.898.11; Fri, 28 Mar 2014 00:17:28 +0000 Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.88]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.88]) with mapi id 15.00.0898.005; Fri, 28 Mar 2014 00:17:28 +0000 From: Marsh Ray To: Martin Thomson Thread-Topic: Nuking DHE in favour of ECDHE (Was: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3) Thread-Index: AQHPShk73DyPcAvUSkSszEOeD742dJr1nl7A Date: Fri, 28 Mar 2014 00:17:27 +0000 Message-ID: <31dba3a928d145c6835d4bbcfa603354@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:ee31::2] x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(51444003)(189002)(199002)(24454002)(81342001)(79102001)(63696002)(15202345003)(46102001)(54356001)(74316001)(74366001)(76796001)(81542001)(77096001)(76786001)(92566001)(76576001)(87936001)(69226001)(2656002)(15975445006)(80022001)(93136001)(65816001)(77982001)(59766001)(56776001)(76482001)(83072002)(85852003)(53806001)(56816005)(90146001)(20776003)(54316002)(98676001)(87266001)(95416001)(81816001)(31966008)(85306002)(93516002)(4396001)(83322001)(47976001)(47736001)(50986001)(49866001)(80976001)(19580395003)(81686001)(19580405001)(74706001)(86362001)(94946001)(51856001)(47446002)(74662001)(86612001)(74502001)(33646001)(97186001)(74876001)(95666003)(97336001)(94316002)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB075; H:BY2PR03MB074.namprd03.prod.outlook.com; FPR:98BFC10D.E16A391.2DCEBFB3.4A038D4D.20245; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lniVplc2rf8kduO3R5SJsM1XpWg Cc: "tls@ietf.org" Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 00:17:35 -0000 RnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dIA0K Pg0KPiBPbiAyNyBNYXJjaCAyMDE0IDE2OjU1LCBNYXJzaCBSYXkgPG1hcmF5QG1pY3Jvc29mdC5j b20+IHdyb3RlOg0KPiA+IEZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQWx5c3NhIFJvd2FuDQo+ID4+DQo+ID4+IFNob3cgb2YgaGFuZHM6IHdobyAq cmVhbGx5KiB3YW50cyB0byBkZXBsb3kgMjA0OC1iaXQgKG9yIGFib3ZlKSBESEUsIHdoZW4gdGhl eSBjb3VsZCBoYXZlIGN1cnZlMjU1MTkgaW5zdGVhZD8NCj4gPg0KPiA+IFRoZSBnZW5lcmFsIGNv bnNlbnN1cyBhdCBNaWNyb3NvZnQgaXMgdGhhdCB3ZSBsaWtlIEVDREhFIG11Y2ggYmV0dGVyIHRo YW4gdGhlIGNsYXNzaWMgREhFLg0KPg0KPiBJIHRoaW5rIHRoYXQgdGhpcyBpcyB0aGUgZ2VuZXJh bCB0cmVuZCwgYnV0IGlzIGl0IHNvIGJhZCB0aGF0IHlvdSB3b3VsZCB3YW50IHRvIHByb2hpYml0 IERIRT8NCg0KSGlzdG9yaWNhbGx5IHdlIGhhdmUgb3B0ZWQgdG8gcHJvdmlkZSBFQ0RIRSAqaW4g cGxhY2Ugb2YqIGNsYXNzaWMgREhFLg0KDQotIE1hcnNoDQoNCmh0dHA6Ly9tc2RuLm1pY3Jvc29m dC5jb20vZW4tdXMvbGlicmFyeS93aW5kb3dzL2Rlc2t0b3AvZmY0Njg2NTEodj12cy44NSkuYXNw eA0KdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnYNClNjaGFu bmVsIENpcGhlciBTdWl0ZXMgaW4gV2luZG93cyBWaXN0YQ0KDQpUTFNfUlNBX1dJVEhfQUVTXzEy OF9DQkNfU0hBDQpUTFNfUlNBX1dJVEhfQUVTXzI1Nl9DQkNfU0hBDQpUTFNfUlNBX1dJVEhfUkM0 XzEyOF9TSEENClRMU19SU0FfV0lUSF8zREVTX0VERV9DQkNfU0hBDQpUTFNfRUNESEVfRUNEU0Ff V0lUSF9BRVNfMTI4X0NCQ19TSEFfUDI1Ng0KVExTX0VDREhFX0VDRFNBX1dJVEhfQUVTXzEyOF9D QkNfU0hBX1AzODQNClRMU19FQ0RIRV9FQ0RTQV9XSVRIX0FFU18xMjhfQ0JDX1NIQV9QNTIxDQpU TFNfRUNESEVfRUNEU0FfV0lUSF9BRVNfMjU2X0NCQ19TSEFfUDI1Ng0KVExTX0VDREhFX0VDRFNB X1dJVEhfQUVTXzI1Nl9DQkNfU0hBX1AzODQNClRMU19FQ0RIRV9FQ0RTQV9XSVRIX0FFU18yNTZf Q0JDX1NIQV9QNTIxDQpUTFNfRUNESEVfUlNBX1dJVEhfQUVTXzEyOF9DQkNfU0hBX1AyNTYNClRM U19FQ0RIRV9SU0FfV0lUSF9BRVNfMTI4X0NCQ19TSEFfUDM4NA0KVExTX0VDREhFX1JTQV9XSVRI X0FFU18xMjhfQ0JDX1NIQV9QNTIxDQpUTFNfRUNESEVfUlNBX1dJVEhfQUVTXzI1Nl9DQkNfU0hB X1AyNTYNClRMU19FQ0RIRV9SU0FfV0lUSF9BRVNfMjU2X0NCQ19TSEFfUDM4NA0KVExTX0VDREhF X1JTQV9XSVRIX0FFU18yNTZfQ0JDX1NIQV9QNTIxDQpUTFNfREhFX0RTU19XSVRIX0FFU18xMjhf Q0JDX1NIQQ0KVExTX0RIRV9EU1NfV0lUSF9BRVNfMjU2X0NCQ19TSEENClRMU19ESEVfRFNTX1dJ VEhfM0RFU19FREVfQ0JDX1NIQQ0KVExTX1JTQV9XSVRIX1JDNF8xMjhfTUQ1DQoNClRoZSBmb2xs b3dpbmcgY2lwaGVyIHN1aXRlcyBhcmUgc3VwcG9ydGVkIGJ5IFNjaGFubmVsOyBob3dldmVyLCB0 aGV5IGFyZSBub3QgcHJlc2VudCBieSBkZWZhdWx0LiBUaGV5IG11c3QgYmUgYWRkZWQgYXMgbmVj ZXNzYXJ5LiBGb3IgaW5mb3JtYXRpb24gYWJvdXQgaG93IHRvIGFkZCBjaXBoZXIgc3VpdGVzIHRv IHRoZSBTY2hhbm5lbCBwcm92aWRlciwgc2VlIFByaW9yaXRpemluZyBTY2hhbm5lbCBDaXBoZXIg U3VpdGVzLg0KVExTX1JTQV9FWFBPUlRfV0lUSF9SQzRfNDBfTUQ1DQpUTFNfUlNBX0VYUE9SVDEw MjRfV0lUSF9SQzRfNTZfU0hBDQpUTFNfUlNBX0VYUE9SVDEwMjRfV0lUSF9ERVNfQ0JDX1NIQQ0K U1NMX0NLX1JDNF8xMjhfRVhQT1JUNDBfTUQ1DQpTU0xfQ0tfREVTXzY0X0NCQ19XSVRIX01ENQ0K VExTX1JTQV9XSVRIX0RFU19DQkNfU0hBDQpUTFNfUlNBX1dJVEhfTlVMTF9NRDUNClRMU19SU0Ff V0lUSF9OVUxMX1NIQQ0KVExTX0RIRV9EU1NfRVhQT1JUMTAyNF9XSVRIX0RFU19DQkNfU0hBDQpU TFNfREhFX0RTU19XSVRIX0RFU19DQkNfU0hBDQpeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXg0K From nobody Thu Mar 27 18:16:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46081A078D for ; Thu, 27 Mar 2014 18:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 J9rID5EeZt27 for ; Thu, 27 Mar 2014 18:16:16 -0700 (PDT) Received: from vsp3.ballou.se (vsp3.ballou.se [91.189.40.101]) by ietfa.amsl.com (Postfix) with SMTP id 6C35F1A0776 for ; Thu, 27 Mar 2014 18:16:14 -0700 (PDT) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp3.ballou.se (Halon Mail Gateway) with ESMTP for ; Fri, 28 Mar 2014 02:13:09 +0100 (CET) Received: from [192.168.0.195] (c-a2c1e555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.193.162]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 048B115A0A0 for ; Fri, 28 Mar 2014 01:56:25 +0100 (CET) Message-ID: <5334C8A8.2020906@streamsec.se> Date: Fri, 28 Mar 2014 01:56:08 +0100 From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/heM2pgmXHV4hzDUjX9gcZmULGjA Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list 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, 28 Mar 2014 01:16:18 -0000 On 2014-03-28 01:09, Watson Ladd wrote: > On Thu, Mar 27, 2014 at 8:04 PM, Martin Thomson > wrote: >> (Renaming the thread, since this is what we seem to be talking about) >> >> On 27 March 2014 16:55, Marsh Ray wrote: >>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Alyssa Rowan >>>> >>>> Show of hands: who *really* wants to deploy 2048-bit (or above) DHE, when they could have curve25519 instead? >>> >>> The general consensus at Microsoft is that we like ECDHE much better than the classic DHE. >> >> I think that this is the general trend, but is it so bad that you >> would want to prohibit DHE? > > Well, the DHE handshake has validation issues: implementations aren't > checking they get sensible inputs. > Fix that, and maybe you have an argument for keeping it. But as it > stands now the insecure resumption attacks are exploiting behavior in > DHE that isn't fixable without a DOS vector being introduced. Pardon for breaking into the conversation, but isn't the attack outlined here https://secure-resumption.com/ actually stopped by the renegotiation indication extension, contrary to what the author states at the page? 1. At the end of the first handshake, the finished messages of the connections C/A and A/S will be different. 2. The outline of the attack rests on the assumption that A might simply forward the messages during the second handshake, because all parameters are the same, and here the finished messages for C/A and A/S will consequently also be the same. Well, they will be if no renegotiation indication extension is included. If it is, this will however be different for C/A and A/S, and hence result in different finished messages after the second handshake as well. Am I missing something obvious? From nobody Thu Mar 27 18:55:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE431A0422 for ; Thu, 27 Mar 2014 18:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzvtWNKTq1I5 for ; Thu, 27 Mar 2014 18:55:53 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 599E21A07B1 for ; Thu, 27 Mar 2014 18:55:53 -0700 (PDT) Received: by mail-yk0-f174.google.com with SMTP id 20so3170893yks.33 for ; Thu, 27 Mar 2014 18:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=cP7RU6MfkcTJgMGpsVXwnXk3DLeNXdjOV86teFY2cfo=; b=slAhk9lJlC812XEK1jnAuntWN7SjtiavRyv6mdRIz9tfhu6C7aztRg2a+Qvy5XAyeJ ID7ZXv8HYDjxMCIp2U2dFpyrM5R6QZD47tNbdLjS2K1nTlI2N0ZxIrJcbx0hL9/6rWWo PNZwFeXOvxIj5cOY6kMwaWp7AMpyIhznptH2uGJWoH5Xu/MFbep75ZoWvgtrT+CDIFpI HAi4btD2C/UBOlt2WZWLWUMeGRHSSTlIYp37wdVdLpRSC7ZG6p8z8B4QAJGIxFaZ2jRW Dpx0VCIEx9a7Bt5Kv1MfiWUGFzw4uVY+SViHnPCKQ08P4W5I21iKqvMNpxOqlbsB2cjC 14gQ== MIME-Version: 1.0 X-Received: by 10.236.222.199 with SMTP id t67mr7080391yhp.86.1395971751217; Thu, 27 Mar 2014 18:55:51 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Thu, 27 Mar 2014 18:55:51 -0700 (PDT) Date: Thu, 27 Mar 2014 21:55:51 -0400 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uPYLhOtlSpcODQavAw7VMY-ogjY Subject: [TLS] TLS 1.3 and existing drafts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Mar 2014 01:55:55 -0000 Dear all: draft-bhargavan-tls-session-hash-00.txt will likely need to be either adopted or obviated (by making the required behavior mandatory) in TLS 1.3: it fixes a real problem, which even eliminating renegotiation doesn't solve. (If we fix the handshake for TLS 1.3, we still need to indicate this in case of fallback) The proposed shift to AEAD schemes only seems to leave behind draft-ietf-tls-encrypt-then-mac-00, unless this is being defined ala AES+GCM, which I don't think it is. In both cases, having two separate fixes, one in TLS 1.2, and one in TLS 1.3 seems like a terrible idea. These drafts have not yet become RFCs, but if we want to avoid having TLS 1.3 as a new version on the wire, we should probably avoid having two distinct solutions for the same problem. Sincerely, Watson Ladd From nobody Thu Mar 27 19:13:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35DA1A0286 for ; Thu, 27 Mar 2014 19:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h91DmvGkfsob for ; Thu, 27 Mar 2014 19:13:37 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 9F86B1A002F for ; Thu, 27 Mar 2014 19:13:37 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 715584768A; Fri, 28 Mar 2014 02:13:35 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 64D6E47689; Fri, 28 Mar 2014 02:13:35 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 6216A8006C; Fri, 28 Mar 2014 02:13:35 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Thu, 27 Mar 2014 22:13:34 -0400 From: "Salz, Rich" To: Watson Ladd , Sean Turner Date: Thu, 27 Mar 2014 22:13:33 -0400 Thread-Topic: [TLS] TLS 1.3 process Thread-Index: Ac9KD81vRX0mqvpfS8iFYnhyH1avmQAG3XzQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE6CE@USMBX1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iPygfITPxwVP4V8f34KR9WuH1HQ Cc: "" Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 02:13:39 -0000 RG9lcyBpdCBtYWtlIHNlbnNlIHRvIGNvbnNpZGVyIHNwbGl0dGluZyB0bHMtbmcgYS9rL2EgdGxz LTIuMCBpbnRvIGEgc2VwYXJhdGUgV0c/DQoNCi0tICANClByaW5jaXBhbCBTZWN1cml0eSBFbmdp bmVlcg0KQWthbWFpIFRlY2hub2xvZ3kNCkNhbWJyaWRnZSwgTUENCg== From nobody Thu Mar 27 20:32:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67451A0046 for ; Thu, 27 Mar 2014 20:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anlRrIv6U6FX for ; Thu, 27 Mar 2014 20:32:29 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id E69871A07C7 for ; Thu, 27 Mar 2014 20:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1395977547; x=1427513547; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=HQiJ/a3l18iWDk6fkKsP0XQXET4pfMzdGsteW6NJkZs=; b=nXQWjo9K/T90tPqzpsl3kIgJXokxJqgcFPwJDyCxrxC9CQ0fRNeTFigi IKFw/MR3GLZJy8I9nLiQunyFX/eKGv3H/25We7A+BWZi/YuHsJ73TIjFr 62FNuNbT9qyoGxb+g2JJyJDLGujfsabAd2Lsov7U/glccL6pFg56egaNl Y=; X-IronPort-AV: E=Sophos;i="4.97,747,1389697200"; d="scan'208";a="243355557" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 28 Mar 2014 16:32:25 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Fri, 28 Mar 2014 16:32:25 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] TLS 1.3 process Thread-Index: Ac9KNlWvN1Mk4NC+SlegrqcqK4PFzw== Date: Fri, 28 Mar 2014 03:32:24 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7372394B5F@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_hPOgqVoQuSCfdt6hxsQNnpURW4 Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 03:32:35 -0000 Trevor Perrin writes:=0A= =0A= >* The WG chairs continue to encourage discussion of goals and design=0A= >alternatives for TLS 1.3. However, the WG holds off from making binding= =0A= >decisions regarding TLS 1.3.=0A= >=0A= >* The WG encourages interested parties to submit proposals for TLS 1.3.=0A= >=0A= >* In X months time (4-6?), the WG chooses which proposal to adopt as the b= ase=0A= >for TLS 1.3, and works to improve it for publication.=0A= =0A= +1. I haven't said much so far because it seems the 1.3 effort is making= =0A= steady progress towards the design-by-committee mess that make IKEv1/IPsec= =0A= such a winner, but I would much prefer the approach of "set boundaries, peo= ple=0A= have six months to submit designs, and then a bake-off". TLS 1.2, which=0A= seemed to consist mostly of gratuitous tweaking of 1.1, has taken years to = see=0A= any uptake (SSL Pulse says about 30%, only slightly above SSLv2, and that's= =0A= for the Alexa top 200K, not the entire net, which I'd expect to be far wors= e=0A= than that), if 1.3 is even more of 1.2 then who knows how long that'll take= =0A= before we see any real uptake.=0A= =0A= In fact I'd be prepared to argue that any work on TLS 1.3 or 2 or whatever= =0A= it's going to be is premature when the vast majority of the net doesn't eve= n=0A= do TLS 1.1 yet, let alone 1.2. What we'll end up with is a bunch of major= =0A= sites doing it and, over a period of several years, browsers gradually=0A= introducing support (Firefox took what, five years?). So if the history of= =0A= TLS 1.1/1.2 is anything to go by, anything we standardise now may start=0A= seeing significant deployment in about the 2020-2025 time frame.=0A= =0A= Peter.= From nobody Thu Mar 27 20:37:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48E81A07C7 for ; Thu, 27 Mar 2014 20:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoJKp7ZrLFgr for ; Thu, 27 Mar 2014 20:37:22 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 00E1A1A0046 for ; Thu, 27 Mar 2014 20:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1395977840; x=1427513840; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ja8+bbD0jfPQYyw04uLRq75SAkG8a0fd1M5zgK36XhA=; b=b2I40TWFXI8J71RuEpbEKVgvKamzqrMWT+oQ0JF2Zd8DfOkjQ3p6YDcJ 4g2x1I8eBrhTDDmnH9ayvNUItbdXlOaApXbykmDJzj463yWvgO+jwGCs1 1XQMsCvMNiLqKVB7B5qLbFNGk7ICqid44SyXElzf0FkWNhgMDlE+8aCiv g=; X-IronPort-AV: E=Sophos;i="4.97,748,1389697200"; d="scan'208";a="243356198" 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; 28 Mar 2014 16:37:19 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Fri, 28 Mar 2014 16:37:19 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Confirming Consensus on supporting only AEAD ciphers Thread-Index: Ac9KNwUkDOjZWEyWQOappzDezTzf1Q== Date: Fri, 28 Mar 2014 03:37:18 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7372394B6C@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fynXsYU5CZrIgBkZfCIb2AD2G2w Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 03:37:23 -0000 Russ Housley writes:=0A= =0A= >Please look at RFC 6476. In that document, Peter Gutmann uses traditional= =0A= >encryption and integrity functions to make an AEAD cipher. Does this=0A= >decision allow or prohibit such ciphers?=0A= =0A= I had a similar question, the EtM draft uses the existing CBC as part of an= =0A= AEAD mechanism, in a manner that requires minimal changes and no=0A= implementation of new cipher modes. Does that count as AEAD, or does it ha= ve=0A= to be a combined cipher mode?=0A= =0A= Peter.= From nobody Thu Mar 27 20:42:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717D61A0046 for ; Thu, 27 Mar 2014 20:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4aHMMAcj4YJ for ; Thu, 27 Mar 2014 20:42:14 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5D01A07C8 for ; Thu, 27 Mar 2014 20:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1395978132; x=1427514132; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=wZX8GXJVq9yGf52buZy6C4FdbzwfJ4H/qdXjPtOsM9Q=; b=IpWyda4l+jiHBph+y80FphXSz/00XH0B3SHtx62gkHTPalni8GErAviA yta7g96HjO08622RVBVfS8+YgkvZNze4HLaOrDEueSs9UrWjIWYsco5v0 CwoVBQAIQ0fnYbvzv+H1o672LL2+K4+JeHaPY/pbjSWx6ix8wEeqOT3D1 k=; X-IronPort-AV: E=Sophos;i="4.97,748,1389697200"; d="scan'208";a="243358470" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 28 Mar 2014 16:42:12 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Fri, 28 Mar 2014 16:42:11 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 Thread-Index: Ac9KN7MUvvKLsQ2+Q9+UUzR/RepAxw== Date: Fri, 28 Mar 2014 03:42:10 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7372394B79@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mbW8j8u7qYb_tSWTpsVIqqhzxB0 Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Mar 2014 03:42:15 -0000 Yaron Sheffer writes:=0A= =0A= >I think this would be a mistake. I would recommend instead to say that=0A= >compression SHOULD be disabled by default. But leave the option in the=0A= >protocol for applications that need compression and are able to mitigate t= he=0A= >vulnerability. This does NOT include normal Web traffic.=0A= =0A= This isn't going to have the effect you think it will. Anyone who has a cl= ue=0A= about security will treat it as a MUST NOT. Anyone who doesn't will say=0A= "cool, it does compression too!" and treat it as a SHOULD or MUST. The onl= y=0A= only way to fix this problem is to remove it entirely.=0A= =0A= Peter.= From nobody Thu Mar 27 21:42:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA571A07D4 for ; Thu, 27 Mar 2014 21:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 GFD0fX-GN4o1 for ; Thu, 27 Mar 2014 21:42:03 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3D91A07D3 for ; Thu, 27 Mar 2014 21:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=957; q=dns/txt; s=iport; t=1395981721; x=1397191321; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WTI5rtELF22t44rCX28GCxWMDOvrbWVOxTJa1MtJrQw=; b=bi613RG8GqUfYkaTu6nHZL4yWCDtVmTqLB9tMJrp/JvaJ+9B7cVVkubm w8M5EtZiBeFHzvExuxSgQ5l3UNWKyFPWUxomMZ5dl0s8E9nG3svvtwSRF 1Ru4cXvFYKLHz1/U+BJYgs0eor452fS2oVHWGg+zt9s0I0c2Hw/y0JijK c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAC79NFOtJV2Z/2dsb2JhbABZDoJ4O1e7MIc3gR0WdIIlAQEBAwEBAQE3NAsFCwIBCA4oECcLJQEBBA4Fh3EIDdFfEwSORzMHgySBFAEDmE2SNIJwP4Ir X-IronPort-AV: E=Sophos;i="4.97,748,1389744000"; d="scan'208";a="31059122" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 28 Mar 2014 04:42:01 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2S4g1pR004972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Mar 2014 04:42:01 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.247]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 27 Mar 2014 23:42:01 -0500 From: "Joseph Salowey (jsalowey)" To: Peter Gutmann Thread-Topic: [TLS] Confirming Consensus on supporting only AEAD ciphers Thread-Index: Ac9KNwUkqiIeFUDRHUase0LCUT6SLgAMvJEA Date: Fri, 28 Mar 2014 04:42:00 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C7372394B6C@uxcn10-6.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7372394B6C@uxcn10-6.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.91] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5nDU-hydivxe4z-yCw_m5fiR8vo Cc: "" Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 04:42:05 -0000 On Mar 27, 2014, at 8:37 PM, Peter Gutmann wrot= e: > Russ Housley writes: >=20 >> Please look at RFC 6476. In that document, Peter Gutmann uses tradition= al >> encryption and integrity functions to make an AEAD cipher. Does this >> decision allow or prohibit such ciphers? >=20 > I had a similar question, the EtM draft uses the existing CBC as part of = an > AEAD mechanism, in a manner that requires minimal changes and no > implementation of new cipher modes. Does that count as AEAD, or does it = have > to be a combined cipher mode? >=20 [Joe] I don't think it counts as an AEAD mechanism. It is not using the AE= AD cipher type defined in RFC 5246. You could define EtM using CBC so th= at it fits the AEAD interface. =20 > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Mar 27 23:38:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549E01A0462 for ; Thu, 27 Mar 2014 23:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.982 X-Spam-Level: X-Spam-Status: No, score=-4.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymQMoOCpjxA4 for ; Thu, 27 Mar 2014 23:38:51 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id 120E81A0468 for ; Thu, 27 Mar 2014 23:38:50 -0700 (PDT) X-IronPort-AV: E=Sophos; i="4.97,749,1389740400"; d="scan'208,217"; a="65115271" Received: from 147.47.192.77.rev.sfr.net (HELO [192.168.1.44]) ([77.192.47.147]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 28 Mar 2014 07:38:48 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_8004C28B-CD0A-4CD8-A96B-7F9E8E7CCC5D" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Karthikeyan Bhargavan In-Reply-To: <5334C8A8.2020906@streamsec.se> Date: Fri, 28 Mar 2014 07:38:47 +0100 Message-Id: References: <5334C8A8.2020906@streamsec.se> To: henrick@streamsec.se X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/po4o2phLLeRku3P6XHthFEx4vFI Cc: tls@ietf.org Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 06:38:53 -0000 --Apple-Mail=_8004C28B-CD0A-4CD8-A96B-7F9E8E7CCC5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Well, the DHE handshake has validation issues: implementations aren't > checking they get sensible inputs. > Fix that, and maybe you have an argument for keeping it. But as it > stands now the insecure resumption attacks are exploiting behavior in > DHE that isn't fixable without a DOS vector being introduced. In regard to DHE validation, one answer (already proposed on this = thread) is to use well-known named groups, instead of arbitrary groups. = So, rather than banning DHE, we could standardise named groups (like = named curves) and ban the use of arbitrary groups (and arbitrary = explicit curves). Still, public key validation remains important for both ECDHE and DHE, = and essential to prevent insecure resumption-like attacks. > 1. At the end of the first handshake, the finished messages of the = connections C/A and A/S will be different. > 2. The outline of the attack rests on the assumption that A might = simply forward the messages during the second handshake, because all = parameters are the same, and here the finished messages for C/A and A/S = will consequently also be the same. Well, they will be if no = renegotiation indication extension is included. If it is, this will = however be different for C/A and A/S, and hence result in different = finished messages after the second handshake as well. Yes, which is why the attack requires 3 handshakes not two. By injecting = a resumption handshake between 1. and 2. above, the finished messages of = C/A and A/S can be made the same. I=92d be happy to discuss off-list. Best, Karthik >=20 > Am I missing something obvious? >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_8004C28B-CD0A-4CD8-A96B-7F9E8E7CCC5D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Well, the DHE handshake has validation = issues: implementations aren't
checking they get sensible = inputs.
Fix that, and maybe = you have an argument for keeping it. But as it
stands now the insecure resumption attacks = are exploiting behavior in
DHE that isn't fixable without a DOS = vector being introduced.

In = regard to DHE validation, one answer (already proposed on this thread) = is to use well-known named groups, instead of arbitrary groups. So, = rather than banning DHE, we could standardise named groups (like named = curves) and ban the use of arbitrary groups (and arbitrary explicit = curves).

Still, public key validation remains = important for both ECDHE and DHE, and essential to prevent insecure = resumption-like attacks.

1. At the end of the first = handshake, the finished messages of the connections C/A and A/S will be = different.
2. The outline of the attack rests on the assumption that = A might simply forward the messages during the second handshake, because = all parameters are the same, and here the finished messages for C/A and = A/S will consequently also be the same. Well, they will be if no = renegotiation indication extension is included. If it is, this will = however be different for C/A and A/S, and hence result in different = finished messages after the second handshake as = well.

Yes, which is why the = attack requires 3 handshakes not two. By injecting a resumption = handshake between 1. and 2. above, the finished messages of C/A and A/S = can be made the same. I=92d be happy to discuss = off-list.

Best,
Karthik

<= /div>

Am = I missing something = obvious?

_______________________________________________
TLS = mailing list
TLS@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tls

= --Apple-Mail=_8004C28B-CD0A-4CD8-A96B-7F9E8E7CCC5D-- From nobody Thu Mar 27 23:49:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08921A0800 for ; Thu, 27 Mar 2014 23:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Et17pcqkOviQ for ; Thu, 27 Mar 2014 23:49:03 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id 33CB41A07FE for ; Thu, 27 Mar 2014 23:49:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,749,1389740400"; d="asc'?scan'208";a="65116879" Received: from 147.47.192.77.rev.sfr.net (HELO [192.168.1.44]) ([77.192.47.147]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 28 Mar 2014 07:49:00 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_79BC9DA6-8794-418A-AAA3-15784FAC53CD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Fri, 28 Mar 2014 07:48:59 +0100 Message-Id: <2CA33889-D7D3-4CA1-AC1D-6BF8B62592EB@inria.fr> References: To: Alyssa Rowan X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IvquAs_DCFUpoPdCZx9afOIQUvQ Cc: "" Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Mar 2014 06:49:05 -0000 --Apple-Mail=_79BC9DA6-8794-418A-AAA3-15784FAC53CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Compression is usually best performed as "high" as possible; transport = layer is blind to what's being compressed, which is (as we now know) was = definitely too low and was in retrospect a mistake. I agree. In particular, note that TLS 1.2 compression is performed on a = per-fragment basis, and hence it leaks even more fine-grained = information about the plaintext than if the compression were performed = for the whole stream in the application.=20 For example, we implemented a traffic-analayzer for fingerprinting = equal-length files over TLS-with-compression [1]. Each file resulted in = about 150 fragments, and our goal was to identify the file by its = compressed length. With TLS compression, we could fingerprint the file within the first = three fragments.With application-level compression we would have needed = to calculate the length of the whole stream. 1: http://www.mitls.org/downloads/miTLS-report.pdf, Section 4.1 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_79BC9DA6-8794-418A-AAA3-15784FAC53CD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTNRtbAAoJEB/WSo9veuUKDswH/16F/BaJAD5zUbxjl9WEOUbu tj49FjB40GVwUD/4sFdoPHQHodu+GjoQ0kbKWAk9OgCE1bk6LxlILmq/0D2uxGqX 15tksun4LMeDawnfW/8ANzLMb1BGttgTlu8a1GdDHsscdllIxrY6PB8q85PQ/GrI KVBcqVcWFqxZtdYQnUMN98HaH6gAiIEtvCOPQbAjWtMD9Bvcq616r28GAzzhAK9S dfnoL3g/VXCluqw6/g7MT1T9g8wcUz82Z8xiwupjmI28TW7Bya9rgEviSPAXOOWd /gQJILPTBwsHiqGyotqThrkfuS7eSdDQ9UZhzChJjqC4qZKWkDBqMdWjQnXa2yg= =NsmV -----END PGP SIGNATURE----- --Apple-Mail=_79BC9DA6-8794-418A-AAA3-15784FAC53CD-- From nobody Fri Mar 28 02:14:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44DE1A04A6 for ; Fri, 28 Mar 2014 02:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6N89oApxtNo for ; Fri, 28 Mar 2014 02:14:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBA51A02CB for ; Fri, 28 Mar 2014 02:14:49 -0700 (PDT) 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 s2S9Ef54012593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Mar 2014 05:14:42 -0400 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 s2S9EdvW001897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Mar 2014 05:14:40 -0400 Message-ID: <1395998078.19721.60.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "Joseph Salowey (jsalowey)" Date: Fri, 28 Mar 2014 10:14:38 +0100 In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C7372394B6C@uxcn10-6.UoA.auckland.ac.nz> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_1ij64M3IDifoTSru4SUwH-IEAk Cc: "" Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 09:14:51 -0000 On Fri, 2014-03-28 at 04:42 +0000, Joseph Salowey (jsalowey) wrote: > >> Please look at RFC 6476. In that document, Peter Gutmann uses traditional > >> encryption and integrity functions to make an AEAD cipher. Does this > >> decision allow or prohibit such ciphers? > > > > I had a similar question, the EtM draft uses the existing CBC as part of an > > AEAD mechanism, in a manner that requires minimal changes and no > > implementation of new cipher modes. Does that count as AEAD, or does it have > > to be a combined cipher mode? > [Joe] I don't think it counts as an AEAD mechanism. It is not using the AEAD cipher type defined in RFC 5246. You could define EtM using CBC so that it fits the AEAD interface. I don't think this is possible. Don't forget that the AEAD mechanism in TLS is only applicable to stream ciphers, i.e, for ciphers that plaintext equals ciphertext. So moving everything to "AEAD" would have to create a new AEAD mode. Overall, I think that this discussion about allowing only the true "AEAD" is pointless. All TLS ciphersuites are Authenticated Encryption by definition and there is no advantage by require them to fit into the TLS true "AEAD" mode. regards, Nikos From nobody Fri Mar 28 02:15:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471661A02CB for ; Fri, 28 Mar 2014 02:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2CUrOEx87-A for ; Fri, 28 Mar 2014 02:15:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDDB1A0874 for ; Fri, 28 Mar 2014 02:15:34 -0700 (PDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2S9FUUl021284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Mar 2014 05:15:30 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s2S9FRh3002602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Mar 2014 05:15:29 -0400 Message-ID: <1395998127.19721.61.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Trevor Perrin Date: Fri, 28 Mar 2014 10:15:27 +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.67 on 10.5.11.11 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z7gJjDlqNKoq31hT_KLlcbMDVjw Cc: "" Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 09:15:35 -0000 On Thu, 2014-03-27 at 16:57 -0700, Trevor Perrin wrote: > On Thu, Mar 27, 2014 at 4:06 PM, Martin Thomson > wrote: > > > > 2. nothing prevents you or anyone from making a proposal...at any time > > Sure, here's my proposal: > > * The WG chairs continue to encourage discussion of goals and design > alternatives for TLS 1.3. However, the WG holds off from making > binding decisions regarding TLS 1.3. > > * The WG encourages interested parties to submit proposals for TLS 1.3. > > * In X months time (4-6?), the WG chooses which proposal to adopt as > the base for TLS 1.3, and works to improve it for publication. I second that. From nobody Fri Mar 28 03:24:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4850E1A04AB for ; Fri, 28 Mar 2014 03:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 frp0UvZrE4nv for ; Fri, 28 Mar 2014 03:24:06 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0011.outbound.protection.outlook.com [213.199.154.11]) by ietfa.amsl.com (Postfix) with ESMTP id 670BC1A010C for ; Fri, 28 Mar 2014 03:24:06 -0700 (PDT) Received: from DBXPRD0210HT002.eurprd02.prod.outlook.com (157.56.253.181) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.0.908.10; Fri, 28 Mar 2014 10:23:58 +0000 Message-ID: <012701cf4a6f$06645e20$4001a8c0@gateway.2wire.net> From: t.petch To: Peter Gutmann , References: <9A043F3CF02CD34C8E74AC1594475C7372394B5F@uxcn10-6.UoA.auckland.ac.nz> Date: Fri, 28 Mar 2014 10:14:14 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.181] X-ClientProxiedBy: AMSPR07CA009.eurprd07.prod.outlook.com (10.242.77.177) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) X-Forefront-PRVS: 01644DCF4A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(377454003)(199002)(189002)(20776003)(47776003)(63696002)(76786001)(77096001)(77156001)(76796001)(50466002)(94946001)(95416001)(95666003)(49866001)(47736001)(77982001)(59766001)(33646001)(50226001)(62236002)(4396001)(97186001)(44716002)(74366001)(97336001)(93136001)(80976001)(85852003)(56816005)(87286001)(87266001)(87976001)(88136002)(90146001)(23756003)(93516002)(93916002)(86362001)(94316002)(89996001)(92726001)(85306002)(83072002)(15975445006)(83322001)(92566001)(76482001)(19580405001)(54316002)(56776001)(61296002)(42186004)(81542001)(51856001)(19580395003)(53806001)(46102001)(31966008)(69226001)(74662001)(98676001)(50986001)(47976001)(62966002)(14496001)(81342001)(74502001)(66066001)(65816001)(80022001)(47446002)(74876001)(74706001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB050; H:DBXPRD0210HT002.eurprd02.prod.outlook.com; FPR:3CE4D175.AD3285CA.BDFB7DA0.45DEFFF9.2034C; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vdCJfUfgQ-4VeuWP4ALCnTjIRH4 Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 10:24:10 -0000 ----- Original Message ----- From: "Peter Gutmann" To: Sent: Friday, March 28, 2014 3:32 AM > Trevor Perrin writes: > > +1. I haven't said much so far because it seems the 1.3 effort is making > steady progress towards the design-by-committee mess that make IKEv1/IPsec > such a winner, but I would much prefer the approach of "set boundaries, people > have six months to submit designs, and then a bake-off". TLS 1.2, which > seemed to consist mostly of gratuitous tweaking of 1.1, has taken years to see > any uptake (SSL Pulse says about 30%, only slightly above SSLv2, and that's > for the Alexa top 200K, not the entire net, which I'd expect to be far worse > than that), if 1.3 is even more of 1.2 then who knows how long that'll take > before we see any real uptake. > > In fact I'd be prepared to argue that any work on TLS 1.3 or 2 or whatever > it's going to be is premature when the vast majority of the net doesn't even > do TLS 1.1 yet, let alone 1.2. What we'll end up with is a bunch of major > sites doing it and, over a period of several years, browsers gradually > introducing support (Firefox took what, five years?). So if the history of > TLS 1.1/1.2 is anything to go by, anything we standardise now may start > seeing significant deployment in about the 2020-2025 time frame. True, but I see another requirement on the TLS WG. As and when we become aware of a new and credible threat, then we should develop a counter for it so that when disaster strikes some part of the Internet as a result of an attack based on the threat, we can say, 'Here is the solution, go implement'. Tom Petch > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Mar 28 04:08:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D421A0522 for ; Fri, 28 Mar 2014 04:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6MTCPiZGYOd for ; Fri, 28 Mar 2014 04:08:16 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id ECB951A0535 for ; Fri, 28 Mar 2014 04:08:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E237CBE9C; Fri, 28 Mar 2014 11:08:11 +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 GJ3dr7W8aUPf; Fri, 28 Mar 2014 11:08:11 +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 B8EF3BE83; Fri, 28 Mar 2014 11:08:11 +0000 (GMT) Message-ID: <5335581D.3020608@cs.tcd.ie> Date: Fri, 28 Mar 2014 11:08:13 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Peter Gutmann , "" References: <9A043F3CF02CD34C8E74AC1594475C7372394B5F@uxcn10-6.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7372394B5F@uxcn10-6.UoA.auckland.ac.nz> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-Y9PgABRoVdJshCdq9Bl_fsAOuY Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 11:08:21 -0000 Peter, On 03/28/2014 03:32 AM, Peter Gutmann wrote: > I haven't said much so far because it seems the 1.3 effort is making > steady progress towards the design-by-committee mess that make IKEv1/IPsec > such a winner, I'm sure others who were more involved will correct me, but wasn't the IKEv1 fun in large part caused by not being able to pick a winner from not-hugely-different competing proposals, with a sprinkling of not easily handled personalities and other competing interests involved? Quoting a recent mail from Jeff Schiller [1]: "The real (or at least the first) problem with the IPSEC working group was that we had a good and simple solution, Photuris. However the document editor on the standard decided to claim it (Photuris) as his intellectual property and that others couldnt recommend changes without his approval. This effectively made Photuris toxic in the working group and we had to move on to other solutions. This is one of the events that lead to the IETFs Note Well document and clear policy on the IP associated with contributions. Then there was the ISAKMP (yes, an NSA proposal) vs. SKIP. As Security AD, I eventually had to choose between those two standards because the working group could not generate consensus. I believed strongly enough that we needed an IPSEC solution so I decided to choose (as I promised the working group I would do if they failed to!). I chose ISAKMP. I posted a message with my rationale to the IPSEC mailing list, Im sure it is still in the archives. I believe that was in 1996 (I still have a copy somewhere in my personal archives)." But anyway, while we don't need to reprise the details of that bit of history, I'm sure we all do agree that not repeating the IKEv1 fun is a high priority goal here and I'm also sure the chairs and many WG participants are taking that into account. (And I'm quite sure the WG just don't want to end up with me having to toss a coin to pick a winner:-) So, FWIW, the chairs process plan seems reasonable to me but its also good to see the WG discussing that. S. [1] http://www.metzdowd.com/pipermail/cryptography/2013-September/017391.html From nobody Fri Mar 28 05:21:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A131A05C3 for ; Fri, 28 Mar 2014 05:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irJHGAfu2T5o for ; Fri, 28 Mar 2014 05:21:12 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 266821A0430 for ; Fri, 28 Mar 2014 05:21:11 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2SCL1R9005738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Mar 2014 08:21:01 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2SCKpTg022778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Mar 2014 08:20:58 -0400 Message-ID: <1396009251.19721.76.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Stephen Farrell Date: Fri, 28 Mar 2014 13:20:51 +0100 In-Reply-To: <5335581D.3020608@cs.tcd.ie> References: <9A043F3CF02CD34C8E74AC1594475C7372394B5F@uxcn10-6.UoA.auckland.ac.nz> <5335581D.3020608@cs.tcd.ie> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0CQ5UWJ6SkOVUXtcX74nlmKfGmY Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 12:21:15 -0000 On Fri, 2014-03-28 at 11:08 +0000, Stephen Farrell wrote: > Peter, > > On 03/28/2014 03:32 AM, Peter Gutmann wrote: > > I haven't said much so far because it seems the 1.3 effort is making > > steady progress towards the design-by-committee mess that make IKEv1/IPsec > > such a winner, > > I'm sure others who were more involved will correct me, > but wasn't the IKEv1 fun in large part caused by not > being able to pick a winner from not-hugely-different > competing proposals, with a sprinkling of not easily > handled personalities and other competing interests > involved? Yes, but I don't think that we can deduct from the issue that competition is bad. I don't know what the details where in the case you describe, and whether the author was justified for refusing changes, but I think that a working group can make clear that any accepted solution will be improved during the WG process. Competition has worked for the TLS protocol, as SSL 3.0 was not product of IETF, but rather the result of competition between SSL from Netscape and PCT by Microsoft, and for its time it was state of the art. The contribution of IETF was minor changes to SSL 3.0 to obtain TLS 1.0 and later by fixing open issues. However, the majority of the TLS protocol was designed outside the IETF processes, and the result I believe was more than satisfactory. regards, Nikos From nobody Fri Mar 28 05:28:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6581A0552 for ; Fri, 28 Mar 2014 05:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fr_r5jW7zEe2 for ; Fri, 28 Mar 2014 05:28:44 -0700 (PDT) Received: from QUTEXEDGE04.qut.edu.au (qutexedge04.qut.edu.au [131.181.191.21]) by ietfa.amsl.com (Postfix) with ESMTP id 724391A031B for ; Fri, 28 Mar 2014 05:28:44 -0700 (PDT) Received: from EX10HT03.qut.edu.au (131.181.108.101) by qutexedge04.qut.edu.au (131.181.191.21) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 28 Mar 2014 22:28:41 +1000 Received: from EX10MB4.qut.edu.au ([169.254.6.172]) by EX10HT03.qut.edu.au ([131.181.108.101]) with mapi id 14.03.0158.001; Fri, 28 Mar 2014 22:28:41 +1000 From: Douglas Stebila To: "" Thread-Topic: [TLS] TLS 1.3 process Thread-Index: AQHPSgZiiOF3YEf/ZUKH5OC10VCCx5r04PEAgAAF2ICAAA4egIAAm+yAgAA1+4A= Date: Fri, 28 Mar 2014 12:28:40 +0000 Message-ID: <0C41E872-6DDD-47DF-98F1-099D9B68D008@qut.edu.au> References: <1395998127.19721.61.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: <1395998127.19721.61.camel@dhcp-2-127.brq.redhat.com> Accept-Language: en-CA, en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.181.118.223] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TByFwZ9FxpjiGEpxenet0ryS90M Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 12:28:47 -0000 On Thu, 2014-03-27 at 16:57 -0700, Trevor Perrin wrote: >> Sure, here's my proposal: >>=20 >> * The WG chairs continue to encourage discussion of goals and design >> alternatives for TLS 1.3. However, the WG holds off from making >> binding decisions regarding TLS 1.3. >>=20 >> * The WG encourages interested parties to submit proposals for TLS 1.3. >>=20 >> * In X months time (4-6?), the WG chooses which proposal to adopt as >> the base for TLS 1.3, and works to improve it for publication. Please leave a healthy dose of time for academic cryptographers to analyze = the protocols and try to develop attacks or proofs of security. Complex me= ssage flows / state machines, like renegotiation and resumption, are hard t= o model and hard to prove. Even if renegotiation is axed, we may have TLS = candidates with complex flows and states, such as a zero round trip protoco= l with partial forward secrecy for parts of the handshake and initial appli= cation data and then the whole connection upgraded to forward secrecy on th= e server reply. Douglas= From nobody Fri Mar 28 06:26:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF5A1A0639 for ; Fri, 28 Mar 2014 06:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZuzMNXXHgoA for ; Fri, 28 Mar 2014 06:25:58 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7442A1A0641 for ; Fri, 28 Mar 2014 06:25:56 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 0B16AF984; Fri, 28 Mar 2014 09:25:51 -0400 (EDT) Message-ID: <5335785F.2070104@fifthhorseman.net> Date: Fri, 28 Mar 2014 09:25:51 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: Marsh Ray , Martin Thomson References: <31dba3a928d145c6835d4bbcfa603354@BY2PR03MB074.namprd03.prod.outlook.com> In-Reply-To: <31dba3a928d145c6835d4bbcfa603354@BY2PR03MB074.namprd03.prod.outlook.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HL9eAr6JrXGBVTbRJctjkQxHO4g467S2v" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vd-W-H-AkHGt0mGz1iZRJMkOilY Cc: "tls@ietf.org" Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 13:26:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HL9eAr6JrXGBVTbRJctjkQxHO4g467S2v Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/27/2014 08:17 PM, Marsh Ray wrote: > From: Martin Thomson [mailto:martin.thomson@gmail.com]=20 >> >> On 27 March 2014 16:55, Marsh Ray wrote: >>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Alyssa Rowan >>>> >>>> Show of hands: who *really* wants to deploy 2048-bit (or above) DHE,= when they could have curve25519 instead? >>> >>> The general consensus at Microsoft is that we like ECDHE much better = than the classic DHE. >> >> I think that this is the general trend, but is it so bad that you woul= d want to prohibit DHE? >=20 > Historically we have opted to provide ECDHE *in place of* classic DHE. did SChannel ever support classic DHE with RSA authentication? http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=3Dv= s.85%29.aspx suggests that XP and win2003 (which, afaict, were what immediately preceded vista) does not have DHE. So it looks like ECDHE was just added, but "classic DHE" wasn't in SChannel in the first place, which doesn't sound like ECDHE is "in place of" DHE to me. or am i misreading the documentation? --dkg --HL9eAr6JrXGBVTbRJctjkQxHO4g467S2v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTNXhfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcbpwQANNnYn3St9BX1ouAfqKRn5kI q7QmHZ7txOfH4BY4NRrbOhCv4kc6Dqp3RviFbe+BbAKX27Y6hyp6HLQAklxCg8EA alNOINdzhHdivbpoib6X/lJ0Q5ztda7FsLmnBZxKaoh1YxLHsM/oyYF2U9uawydo RbW9CBu7UfU8lP1mmcXwBFCLbMw3iwESoZL6zUS78El2kX8FW0tRLhLgQPYOqTnV eFftKEY40lFthAUe63tMoV8ywRcZpu9cuySZPAIat7qwySZKqMOgvWsVBd1o/U6E ZWcQlfGY9J+AUvkq0fDTLzRbjruXojKLrkG4Bm8zJLX+GLZ2a/Sr8rV+dQgaNSTD 5ip5VY7NL68w6ozEe7QhSmpJH/bWcHObpfWBaZuEnzaopCNJbtL36VdV+G77+jBj MVgxjbDbqj84bYR7hFrIIovzBNqi1Kgp5QN3u3O+BEsOrjif/ogzPHszliT699tZ J07Je7CVR1qPF8PymEBGU8hxQNrgnSfzXWtK48gs5N1e64qJtqIBdO2Yg8rGLYrN P9D3oeaiP4fJLb8WvvMLClqLAquS6kq1RrVu31z1xEqbDM1ZSrfCB2ox2ouXg55h wY+CEVkxODgyW3WQgMl8TjbpXvp/a5xgnTD/LT9Msn+8lK2YJeNjZiulZnWE/V/Z yYdZUOOr1Nao1f1x9Zh+ =Vfcv -----END PGP SIGNATURE----- --HL9eAr6JrXGBVTbRJctjkQxHO4g467S2v-- From nobody Fri Mar 28 06:58:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC0F1A064F for ; Fri, 28 Mar 2014 06:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcoja06BOKtg for ; Fri, 28 Mar 2014 06:58:34 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1111A0648 for ; Fri, 28 Mar 2014 06:58:34 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hm4so777852wib.2 for ; Fri, 28 Mar 2014 06:58:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lh/+2amA+N644ayvtE/K3wQ647EvRFZx2wWqp2p6Ohw=; b=TwFPGr0vn4OTDnMcwVbWLJ5c2fH83tOHmgKOwBIP2agyAsl112JBpla92sJAYaRmfP UD8sJxZuDmgI4MY2rK47T3VNI82ISijNwo8s1WKdU0C7y6/IsX3SLV889VkEte9I4WsY ILP4kSvLQ91yvUBqP3NQW08z7/Z1CbOphn8lNuwgVL2X1Ytf0uAYZTCRgMmk7X/a6VAD SLoP4FLYFcSRz+bG71iQtAVgdT5mWEAo/epLkvLKQGRUR05WvT+CZQ8QLrCh+jEvZh9G 2mj8KHHEs3URVUKYvOUwysNhPdxJcEsQjngUcWP1AhX1gB5nS4o+nY0PAXkXwk5foEOT yHjQ== X-Gm-Message-State: ALoCoQlzoB3RLaRRl9MWaBgodHuFp0Qpi57O7o97VJ8783xxEx2p5Hi4oyOHb/wbw1fK9cCVseBI X-Received: by 10.180.9.42 with SMTP id w10mr12898802wia.20.1396015111723; Fri, 28 Mar 2014 06:58:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Fri, 28 Mar 2014 06:57:14 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <1395998078.19721.60.camel@dhcp-2-127.brq.redhat.com> References: <9A043F3CF02CD34C8E74AC1594475C7372394B6C@uxcn10-6.UoA.auckland.ac.nz> <1395998078.19721.60.camel@dhcp-2-127.brq.redhat.com> From: Eric Rescorla Date: Fri, 28 Mar 2014 06:57:14 -0700 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=001a11c247acd5f3c604f5ab18bf Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DWGqEs7d4XlSaXPq6H6jPpdYXf4 Cc: "" Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 13:58:36 -0000 --001a11c247acd5f3c604f5ab18bf Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 28, 2014 at 2:14 AM, Nikos Mavrogiannopoulos wrote: > On Fri, 2014-03-28 at 04:42 +0000, Joseph Salowey (jsalowey) wrote: > > > >> Please look at RFC 6476. In that document, Peter Gutmann uses > traditional > > >> encryption and integrity functions to make an AEAD cipher. Does this > > >> decision allow or prohibit such ciphers? > > > > > > I had a similar question, the EtM draft uses the existing CBC as part > of an > > > AEAD mechanism, in a manner that requires minimal changes and no > > > implementation of new cipher modes. Does that count as AEAD, or does > it have > > > to be a combined cipher mode? > > [Joe] I don't think it counts as an AEAD mechanism. It is not using the > AEAD cipher type defined in RFC 5246. You could define EtM using CBC so > that it fits the AEAD interface. > > I don't think this is possible. Don't forget that the AEAD mechanism in > TLS is only applicable to stream ciphers, i.e, for ciphers that > plaintext equals ciphertext. So moving everything to "AEAD" would have > to create a new AEAD mode. > This is fairly straightforward to address by simply adopting the same length approach that Peter's draft adopts. Yes, we would need to update the text, but since we're talking about a new document that doesn't seem like a problem. Overall, I think that this discussion about allowing only the true > "AEAD" is pointless. All TLS ciphersuites are Authenticated Encryption > by definition and there is no advantage by require them to fit into the > TLS true "AEAD" mode. > The idea here is that TLS currently specifies *in TLS* how to compose authentication and encryption which means that we have to specify three interfaces for three different kinds of ciphers (stream, block, AEAD). Since cryptographic practice seems to be moving towards AEAD as a primitive, we have an opportunity to simplify matters by going to an AEAD only interface which also has the virtue of having to specify specific constructions in TLS. -Ekr --001a11c247acd5f3c604f5ab18bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 28, 2014 at 2:14 AM, Nikos Mavrogiannopoulos <nmav@redh= at.com> wrote:
On Fri, 2014-03-28 at 04:42 = +0000, Joseph Salowey (jsalowey) wrote:

> >> Please look at RFC 6476. =A0In that document, Peter Gutmann u= ses traditional
> >> encryption and integrity functions to make an AEAD cipher. = =A0Does this
> >> decision allow or prohibit such ciphers?
> >
> > I had a similar question, the EtM draft uses the existing CBC as = part of an
> > AEAD mechanism, in a manner that requires minimal changes and no<= br> > > implementation of new cipher modes. =A0Does that count as AEAD, o= r does it have
> > to be a combined cipher mode?
> [Joe] I don't think it counts as an AEAD mechanism. =A0It is not u= sing the AEAD =A0cipher type defined in RFC 5246. =A0 You could define EtM = using CBC so that it fits the AEAD interface.

I don't think this is possible. Don't forget that the AEAD me= chanism in
TLS is only applicable to stream ciphers, i.e, for ciphers that
plaintext equals ciphertext. So moving everything to "AEAD" would= have
to create a new AEAD mode.

This is fair= ly straightforward to address by simply adopting
the same length = approach that Peter's draft adopts. Yes, we
would need to upd= ate the text, but since we're talking about
a new document that doesn't seem like a problem.


Overall, I think that this discussion about allowing only the true
"AEAD" is pointless. All TLS ciphersuites are Authenticated Encry= ption
by definition and there is no advantage by require them to fit into the
TLS true "AEAD" mode.

The ide= a here is that TLS currently specifies *in TLS* how to compose
au= thentication and encryption which means that we have to specify
three interfaces for three different kinds of ciphers (stream, block, AEAD)= .
Since cryptographic practice seems to be moving towards AEAD as=
a primitive, we have an opportunity to simplify matters by going= to
an AEAD only interface which also has the virtue of having to specify<= /div>
specific constructions in TLS.

-Ekr



--001a11c247acd5f3c604f5ab18bf-- From nobody Fri Mar 28 07:10:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EC01A0684 for ; Fri, 28 Mar 2014 07:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBQgShJrehoe for ; Fri, 28 Mar 2014 07:10:40 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5091A065A for ; Fri, 28 Mar 2014 07:10:40 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id r20so794388wiv.3 for ; Fri, 28 Mar 2014 07:10:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8RW7/yY3IfUe42csHJG51AvU1V+lhuSO2fT1hyfdbAc=; b=XBQEbQu5nfZ7hgdw7W2mm7RfXTgG646R6yaLXHSlRdmkzeaIPYCB6bwW/d9vmDlaj3 tifsNZorDjMP/xvBd6OOVrsGY0zCskHlni1X8yHuqcxUpbJds2si1wANTod4YxKA25zD hX4l7trw0aqOnRpTFmdFX+cvKGvytxm++vDj/UlV/8r9zNfzwYqUxdM3cd5c8EHl9TPJ AGvdVvJI4GrS71Waq/SaiJFeiWGAtacZpB44zkSAmesLK7Mr6ZLgR34s9WWG1Ifh93bl aPrEqI9NqGe2ocuiTElyp3oVWL2ZPbGc7MDJgJDyROvIDm4qB8Ubeg/cQmQ/qRGr4weA dvmA== X-Gm-Message-State: ALoCoQlTB07Kd2nkHe2kOi4hmF9aP6ft+qJ/VycABHFocPn4AfgHr9wU0rb6vHC+yT6a+3JooeV5 X-Received: by 10.180.81.228 with SMTP id d4mr21475385wiy.49.1396015837673; Fri, 28 Mar 2014 07:10:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Fri, 28 Mar 2014 07:09:57 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <5334C8A8.2020906@streamsec.se> From: Eric Rescorla Date: Fri, 28 Mar 2014 07:09:57 -0700 Message-ID: To: Karthikeyan Bhargavan Content-Type: multipart/alternative; boundary=f46d043bdb0e1b1f3f04f5ab4476 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RrX8jliSCGjb0awFeUB4ilK1W_c Cc: "tls@ietf.org" Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 14:10:44 -0000 --f46d043bdb0e1b1f3f04f5ab4476 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 27, 2014 at 11:38 PM, Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > > Well, the DHE handshake has validation issues: implementations aren't > > checking they get sensible inputs. > > Fix that, and maybe you have an argument for keeping it. But as it > > stands now the insecure resumption attacks are exploiting behavior in > DHE that isn't fixable without a DOS vector being introduced. > > > In regard to DHE validation, one answer (already proposed on this thread) > is to use well-known named groups, instead of arbitrary groups. So, rather > than banning DHE, we could standardise named groups (like named curves) and > ban the use of arbitrary groups (and arbitrary explicit curves). > Note that we could do this for TLS 1.x not just for TLS 1.3, though obviously we couldn't *require* standardized groups for older versions for compatibility reasons. WRT group validation being a DoS vector (a point made by Watson), the effect of the DoS seems somewhat limited by the fact that it's the server who selects the group and therefore the client who has to validate it, so you can't push arbitrary computational load onto some server just by connecting to them and forcing it to validate parameters (though of course you can already do so to some extent by forcing them to do signatures, key exchanges, etc.) This isn't to say that DoS of clients isn't a potentially big deal but at least in the Web context any network attacker can force arbitrary amounts of computation onto the client just by pushing JS into any HTTP connection [0]. Outside the Web context, there probably are cases where this would be a more viable attack, though depending on the cost of validation they might require the client to also be willing to do a lot of reconnects automatically in order to be really affected. -Ekr [0] And of course in Karthik's attack, the assumption is that the client would connect to the attack server in any case and so even in an all HTTPS world, the attacker could shove down arbitrary JS from his own site. Still, public key validation remains important for both ECDHE and DHE, and > essential to prevent insecure resumption-like attacks. > > 1. At the end of the first handshake, the finished messages of the > connections C/A and A/S will be different. > 2. The outline of the attack rests on the assumption that A might simply > forward the messages during the second handshake, because all parameters > are the same, and here the finished messages for C/A and A/S will > consequently also be the same. Well, they will be if no renegotiation > indication extension is included. If it is, this will however be different > for C/A and A/S, and hence result in different finished messages after the > second handshake as well. > > > Yes, which is why the attack requires 3 handshakes not two. By injecting a > resumption handshake between 1. and 2. above, the finished messages of C/A > and A/S can be made the same. I'd be happy to discuss off-list. > > Best, > Karthik > > > > Am I missing something obvious? > > _______________________________________________ > 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 > > --f46d043bdb0e1b1f3f04f5ab4476 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 27, 2014 at 11:38 PM, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> wrote:

Well, the DHE handshake has validati= on issues: implementations aren't
checking they get sensible inputs.
Fix that, and maybe you have an argument for keeping it. But as it
stands now the insecure resumption attack= s are exploiting behavior in
DHE that isn't fixable without a DOS ve= ctor being introduced.

In regard to DHE validation, o= ne answer (already proposed on this thread) is to use well-known named grou= ps, instead of arbitrary groups. So, rather than banning DHE, we could stan= dardise named groups (like named curves) and ban the use of arbitrary group= s (and arbitrary explicit curves).

Note that we could do this for= TLS 1.x not just for TLS 1.3, though
obviously we couldn't *= require* standardized groups for older
versions for compatibility= reasons.

WRT group validation being a DoS vector (a point made b= y Watson),
the effect of the DoS seems somewhat limited by the fa= ct that it's the server who selects the group and therefore the client = who has to validate it, so you can't push arbitrary computational load = onto some server just by connecting
to them and forcing it to validate parameters (though of course you ca= n
already do so to some extent by forcing them to do signatures, = key
exchanges, etc.)

This isn't to s= ay that DoS of clients isn't a potentially big deal but at least in the= Web context any network attacker can force arbitrary amounts of computatio= n onto the client just by pushing JS into any HTTP connection [0]. Outside = the Web context, there probably are cases where this would be a
more viable attack, though depending on the cost of validation they
might require the client to also be willing to do a lot of reconnec= ts
automatically in order to be really affected.

-Ekr

[0] And of course in Karthik's= attack, the assumption is that the client
would connect to the a= ttack server in any case and so even in an
all HTTPS world, the a= ttacker could shove down arbitrary JS from
his own site.


Still, public key v= alidation remains important for both ECDHE and DHE, and essential to preven= t insecure resumption-like attacks.

1. At the end of the first handshake, the finished messages of the connecti= ons C/A and A/S will be different.
2. The outline of the attack rests on= the assumption that A might simply forward the messages during the second = handshake, because all parameters are the same, and here the finished messa= ges for C/A and A/S will consequently also be the same. Well, they will be = if no renegotiation indication extension is included. If it is, this will h= owever be different for C/A and A/S, and hence result in different finished= messages after the second handshake as well.

Yes, which is why the attack r= equires 3 handshakes not two. By injecting a resumption handshake between 1= . and 2. above, the finished messages of C/A and A/S can be made the same. = I’d be happy to discuss off-list.

Best,
Karthik

<= /div>

Am I missing something obvious?

________________________________= _______________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


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


--f46d043bdb0e1b1f3f04f5ab4476-- From nobody Fri Mar 28 07:12:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1AC1A0668 for ; Fri, 28 Mar 2014 07:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJNewJfGXvKD for ; Fri, 28 Mar 2014 07:12:35 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 482A81A065A for ; Fri, 28 Mar 2014 07:12:35 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DBBB2480C8 for ; Fri, 28 Mar 2014 14:12:32 +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 CFB2C482E8 for ; Fri, 28 Mar 2014 14:12:32 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 9F65947BD2 for ; Fri, 28 Mar 2014 14:12:31 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Fri, 28 Mar 2014 10:12:31 -0400 From: "Salz, Rich" To: "" Date: Fri, 28 Mar 2014 10:12:30 -0400 Thread-Topic: [TLS] TLS 1.3 process Thread-Index: Ac9KBl4J0vN1MCo2RDuY6VdusdWJbgAh8Jww Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE833@USMBX1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FfVRWLUf_78LhvY457WNCEoM0bI Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 14:12:40 -0000 > The TLS WG charter is pretty clear that the intention isn't to design a c= ompletely new protocol but rather to revise TLS, > and specifically to "place a priority in minimizing gratuitous changes to= TLS." +1. It seems to me that there are almost three viewpoints within this WG. With= the hope that I'm equally unfair to everyone, I'd summarize them like this= : - Update to modern crypto knowledge to fix bugs, and some modern features = and be done - Make big changes to fix serious problems - Start over from a clean sheet; "I don't know what it will be, but we'll = call it TLS." I put myself in the first group (except for SNI encryption, which will get = a separate post :), could be convinced to support something from the second= once it's written down, and am probably not qualified to evaluate anything= from the third group (few people are). Interestingly, barring divine inter= vention, the above list is probably in order of length of time needed, as w= ell. That would seem to indicate that there's room for all three efforts he= re. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Fri Mar 28 07:16:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB58F1A0695 for ; Fri, 28 Mar 2014 07:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93BRVoD__bCc for ; Fri, 28 Mar 2014 07:16:31 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFBB1A0668 for ; Fri, 28 Mar 2014 07:16:31 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id a41so5008007yho.4 for ; Fri, 28 Mar 2014 07:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WAJg2HOnDoUgjzIA3frrwkpDB9dwGNHXj6ilzDfk5zw=; b=bC+P24N6kszpkh/dE7X9VCRA4D/BuKWpRPf3PgM6qeNuD/SpX+sWNmSISgPh4qpqw9 XkojbOEjlpLcFfdf0eYJdIZaXQwNZU/eF8wTu6ecN+mj23gS2h29uLbuVLcIdX3fYNeW L+fMuvHxg1cYzlxLSfXIKIlzpxGKoh/UWp8o6pbalmuRFWVnUlbiCmgWEU7vcCS+pNd4 yW74eXukXiN+19RbM9kgMCzPuFixS767aEhzkT8hI2WsR6W9uruw0ES2JkGb0cYbRj1F 8hYLIOtqSSWqG++tpIWL6//0AAUexZsqPo2TPYX0ajFKtaVSynQJU5tGRXAYFCHNBTDj 1P4A== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr11744538yhi.4.1396016189127; Fri, 28 Mar 2014 07:16:29 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Fri, 28 Mar 2014 07:16:29 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C7372394B6C@uxcn10-6.UoA.auckland.ac.nz> <1395998078.19721.60.camel@dhcp-2-127.brq.redhat.com> Date: Fri, 28 Mar 2014 10:16:29 -0400 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FRF2ORJ7VCGaXMgrhW6DFXaoE00 Cc: "" Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 14:16:33 -0000 On Fri, Mar 28, 2014 at 9:57 AM, Eric Rescorla wrote: > > > > On Fri, Mar 28, 2014 at 2:14 AM, Nikos Mavrogiannopoulos > wrote: >> >> On Fri, 2014-03-28 at 04:42 +0000, Joseph Salowey (jsalowey) wrote: >> >> > >> Please look at RFC 6476. In that document, Peter Gutmann uses >> > >> traditional >> > >> encryption and integrity functions to make an AEAD cipher. Does this >> > >> decision allow or prohibit such ciphers? >> > > >> > > I had a similar question, the EtM draft uses the existing CBC as part >> > > of an >> > > AEAD mechanism, in a manner that requires minimal changes and no >> > > implementation of new cipher modes. Does that count as AEAD, or does >> > > it have >> > > to be a combined cipher mode? >> > [Joe] I don't think it counts as an AEAD mechanism. It is not using the >> > AEAD cipher type defined in RFC 5246. You could define EtM using CBC so >> > that it fits the AEAD interface. >> >> I don't think this is possible. Don't forget that the AEAD mechanism in >> TLS is only applicable to stream ciphers, i.e, for ciphers that >> plaintext equals ciphertext. So moving everything to "AEAD" would have >> to create a new AEAD mode. > > > This is fairly straightforward to address by simply adopting > the same length approach that Peter's draft adopts. Yes, we > would need to update the text, but since we're talking about > a new document that doesn't seem like a problem. > > >> Overall, I think that this discussion about allowing only the true >> "AEAD" is pointless. All TLS ciphersuites are Authenticated Encryption >> by definition and there is no advantage by require them to fit into the >> TLS true "AEAD" mode. > > > The idea here is that TLS currently specifies *in TLS* how to compose > authentication and encryption which means that we have to specify > three interfaces for three different kinds of ciphers (stream, block, AEAD). > Since cryptographic practice seems to be moving towards AEAD as > a primitive, we have an opportunity to simplify matters by going to > an AEAD only interface which also has the virtue of having to specify > specific constructions in TLS. So let me get this straight: what we are planning to do is eliminate the current MAC-encryption layer, and instead have a layer that takes a plaintext TLS record and encapsulates as an encrypted one. The TLS spec specifies the inputs, and the cipher has to specify how to go from inputs to ciphertext, and be IND-CCA2+INT_PTXT secure. This has a major advantage in that we lose a lot of length and complexity from the spec. I don't see any disadvantages. Sincerely, Watson Ladd > > -Ekr > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Mar 28 07:24:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4D61A0813 for ; Fri, 28 Mar 2014 07:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIDrxKCW_xAX for ; Fri, 28 Mar 2014 07:24:08 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id A758C1A0699 for ; Fri, 28 Mar 2014 07:24:07 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so815967wiw.6 for ; Fri, 28 Mar 2014 07:24:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KUCyA9bY7xLL0OVl+oTMyPQ1ypG+4CBPsSXLe4Rvg9A=; b=Iv+AMcJ6BEgHjE21nQn1TnCb1/qHjq1C5xGtpCmpg304J3b2p761ZechdpV2TLnH4g JXeRuF7SHpXdSgtpwW0gd5Cxr2zelA1ITQ2bpzEj3Xt4MXd3BFpLeWp+ock2yhHyOH0r WBKzdfhN53GkGfOpvcNhj3MNb+fTNbw8EJlEodbDpCH1/96DXSGzUEARj2Bf0bJNYE2b b4SKv7bzcAZj7v3rb1uA81gmLywy00PFEBF/dkSVI2q59YSPxxjd9Z2CHXyMMyLkUNGj ER5yHpz0CT+z/BCIExHaXXd/U+bPjzyuSPKtSToJ0DTc17intboeSK5zkmzvwjhUPd0O npGw== X-Gm-Message-State: ALoCoQl+1CuJFnilQelzngj9svDKqC3qqsbOlRMIL09QGvAXu7KgLjgFAAwIaA6XI2gk3DJtpTjF X-Received: by 10.180.90.140 with SMTP id bw12mr13173728wib.18.1396016645044; Fri, 28 Mar 2014 07:24:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Fri, 28 Mar 2014 07:23:24 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C7372394B6C@uxcn10-6.UoA.auckland.ac.nz> <1395998078.19721.60.camel@dhcp-2-127.brq.redhat.com> From: Eric Rescorla Date: Fri, 28 Mar 2014 07:23:24 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=f46d043c811a3a900f04f5ab7483 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/W16uw__r83LeePcpbb9fpM8KKX8 Cc: "" Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 14:24:09 -0000 --f46d043c811a3a900f04f5ab7483 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 28, 2014 at 7:16 AM, Watson Ladd wrote: > On Fri, Mar 28, 2014 at 9:57 AM, Eric Rescorla wrote: > > > > The idea here is that TLS currently specifies *in TLS* how to compose > > authentication and encryption which means that we have to specify > > three interfaces for three different kinds of ciphers (stream, block, > AEAD). > > Since cryptographic practice seems to be moving towards AEAD as > > a primitive, we have an opportunity to simplify matters by going to > > an AEAD only interface which also has the virtue of having to specify > > specific constructions in TLS. > > So let me get this straight: what we are planning to do is eliminate > the current MAC-encryption layer, and instead have a layer that takes > a plaintext TLS record and encapsulates as an encrypted one. The TLS > spec specifies the inputs, and the cipher has to specify how to go > from inputs to ciphertext and be IND-CCA2+INT_PTXT secure. Assuming I understand you correctly, then yes, this sounds right, with the small caveat that we would probably not leave the question of how to format the cleartext part of the (otherwise encrypted) record header up to the cipher, since that's a TLS issue, though we would expect it to be covered as part of the "additional data". This has a major advantage in that we lose a lot of length and > complexity from the spec. This was my thinking as well. -Ekr --f46d043c811a3a900f04f5ab7483 Content-Type: text/html; charset=ISO-8859-1



On Fri, Mar 28, 2014 at 7:16 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
On Fri, Mar 28, 2014 at 9:57 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> The idea here is that TLS currently specifies *in TLS* how to compose
> authentication and encryption which means that we have to specify
> three interfaces for three different kinds of ciphers (stream, block, AEAD).
> Since cryptographic practice seems to be moving towards AEAD as
> a primitive, we have an opportunity to simplify matters by going to
> an AEAD only interface which also has the virtue of having to specify
> specific constructions in TLS.

So let me get this straight: what we are planning to do is eliminate
the current MAC-encryption layer, and instead have a layer that takes
a plaintext TLS record and encapsulates as an encrypted one. The TLS
spec specifies the inputs, and the cipher has to specify how to go
from inputs to ciphertext and be IND-CCA2+INT_PTXT secure.

Assuming I understand you correctly, then yes, this sounds right,
with the small caveat that we would probably not leave the question
of how to format the cleartext part of the (otherwise encrypted)
record header up to the cipher, since that's a TLS issue, though
we would expect it to be covered as part of the "additional data".


This has a major advantage in that we lose a lot of length and
complexity from the spec.

This was my thinking as well.

-Ekr

--f46d043c811a3a900f04f5ab7483-- From nobody Fri Mar 28 08:01:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735C01A06C6 for ; Fri, 28 Mar 2014 08:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q72aNs7Z7uxk for ; Fri, 28 Mar 2014 08:01:54 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA921A065A for ; Fri, 28 Mar 2014 08:01:53 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 142so826956ykq.41 for ; Fri, 28 Mar 2014 08:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nhn4LqOTD0qMLok8E2B5T6nDqgIoFBrPZYV6hG1w/Cg=; b=CNRnKXJsNaq9VN6lSmWQ+IafIbY5uX4j7JjvdYFjfW9NMQtwtLctJDiACBN8l8XUr+ KwkT7ezrjSKcjb8zu2h9DMsW0cpdP0GMQKIxaDcAEgvyj/+RC/U1Smi3tRDWo/laA2LN qoWa/cIN1p4iccWWiBFFvH5A7cuwhSPMYx/Toj2ME4orfiwkYs/l1xHD8uoTF5cdeAcG wNFUjDigNj3ITVPTPjOqdgGah1o1VxzdLTQfDIdhwSDT8o/Oh9AgwwypPacdNLJZBT1q g5dR8J4AugmSyN6G3X+qqENd7EbHV1HdD8PjWFOnS9Kzp7Fw2E5M+K513l1wGk29d4qN rdUA== MIME-Version: 1.0 X-Received: by 10.236.179.162 with SMTP id h22mr3854577yhm.107.1396018911792; Fri, 28 Mar 2014 08:01:51 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Fri, 28 Mar 2014 08:01:51 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE833@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE833@USMBX1.msg.corp.akamai.com> Date: Fri, 28 Mar 2014 11:01:51 -0400 Message-ID: From: Watson Ladd To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_idErTKTFJCtTSz0a0YEWwuHQa4 Cc: "" Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 15:01:55 -0000 On Fri, Mar 28, 2014 at 10:12 AM, Salz, Rich wrote: >> The TLS WG charter is pretty clear that the intention isn't to design a = completely new protocol but rather to revise TLS, >> and specifically to "place a priority in minimizing gratuitous changes t= o TLS." > > +1. > > It seems to me that there are almost three viewpoints within this WG. Wi= th the hope that I'm equally unfair to everyone, I'd summarize them like th= is: > - Update to modern crypto knowledge to fix bugs, and some modern = features and be done > - Make big changes to fix serious problems > - Start over from a clean sheet; "I don't know what it will be, b= ut we'll call it TLS." > > I put myself in the first group (except for SNI encryption, which will ge= t a separate post :), could be convinced to support something from the seco= nd once it's written down, and am probably not qualified to evaluate anythi= ng from the third group (few people are). Interestingly, barring divine int= ervention, the above list is probably in order of length of time needed, as= well. That would seem to indicate that there's room for all three efforts = here. I think the first issue should be our biggest priority: leave the handshake largely alone, focus on fixing insecure resumption and the record layer, removing compression, mandate secure renegotiation, document 1/N-1 record splitting. All of this needs to be done in TLS 1.2, and there are drafts for most of it already. Once that's done, we can turn to things like zero-round handshakes and caching and encryption of handshakes. As much as I like 3, I don't think it will ever happen. Maybe IoT will be looking for something much more lightweight? There are alternatives like MinimalLT and CurveCP, but takeup is understandably slow. Sincerely, Watson Ladd > > /r$ > > -- > 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 nobody Fri Mar 28 08:14:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417811A069C for ; Fri, 28 Mar 2014 08:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yZLIy37G3ze for ; Fri, 28 Mar 2014 08:13:55 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id CAAAB1A0668 for ; Fri, 28 Mar 2014 08:13:54 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id v1so5090430yhn.40 for ; Fri, 28 Mar 2014 08:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jaBtlWTe5On40sNP2hgWDVp4qoJm4sZ28IukpNhjz18=; b=gY5U3vNT77ROuQeysfY6kiAWLcW9fjqQqv+/lSSK59PsCXsxzrt6M5jr1tujfs90M+ I6TCdpG3gdtpNlAhElPM3l2uWq00xj/DbfVXpc4dXsSr6Ym5jG6YRTSa12plRYTV5Gxa qHWSh9PVSkh2tD30gj8vBr9sjfYwWrrOgZVITS7c81BJc+X4rEGcWNMW7fncSq8M0fu8 HVXl2V8MAUSKlxCM3ElraCv3cZWoXiu+Z2yrAoo8WPJIsVD0ropKDsWNsZzxdDvYRy93 Y7mNrgfP6sr8MheFk2jTdcXYCwxfzt2AjYWKaXEWuvhGPh/textQd1sCcKr35B43T89G ZmQQ== MIME-Version: 1.0 X-Received: by 10.236.90.12 with SMTP id d12mr2830525yhf.120.1396019632568; Fri, 28 Mar 2014 08:13:52 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Fri, 28 Mar 2014 08:13:52 -0700 (PDT) In-Reply-To: References: <5334C8A8.2020906@streamsec.se> Date: Fri, 28 Mar 2014 11:13:52 -0400 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2t4ffd76Nvt3UxcVhMagvRjwgUg Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 15:13:57 -0000 On Fri, Mar 28, 2014 at 10:09 AM, Eric Rescorla wrote: > > > > On Thu, Mar 27, 2014 at 11:38 PM, Karthikeyan Bhargavan > wrote: >> >> >> Well, the DHE handshake has validation issues: implementations aren't >> >> checking they get sensible inputs. >> >> Fix that, and maybe you have an argument for keeping it. But as it >> >> stands now the insecure resumption attacks are exploiting behavior in >> DHE that isn't fixable without a DOS vector being introduced. >> >> >> In regard to DHE validation, one answer (already proposed on this thread= ) >> is to use well-known named groups, instead of arbitrary groups. So, rath= er >> than banning DHE, we could standardise named groups (like named curves) = and >> ban the use of arbitrary groups (and arbitrary explicit curves). > > > Note that we could do this for TLS 1.x not just for TLS 1.3, though > obviously we couldn't *require* standardized groups for older > versions for compatibility reasons. > > WRT group validation being a DoS vector (a point made by Watson), > the effect of the DoS seems somewhat limited by the fact that it's the > server who selects the group and therefore the client who has to validate > it, so you can't push arbitrary computational load onto some server just = by > connecting > to them and forcing it to validate parameters (though of course you can > already do so to some extent by forcing them to do signatures, key > exchanges, etc.) Validating a DH group requires factoring p-1 and determining that it has a large nonsmooth part, as well as determining p is prime. This is a lot of work, which is why clients don't do it. (Even if we demand that p-1 have no prime factors up to 256 bit there isn't a good way to do that beyond factoring[1]). On my rather nice machine, running gp and asking it to factor 2^1024-epsilon takes a long time. The DoS is from one connection, not many. As for Javascript, web browsers have to deal with scripts running overtime already. It's a much easier problem. Sincerely, Watson Ladd > > This isn't to say that DoS of clients isn't a potentially big deal but at > least in the Web context any network attacker can force arbitrary amounts= of > computation onto the client just by pushing JS into any HTTP connection [= 0]. > Outside the Web context, there probably are cases where this would be a > more viable attack, though depending on the cost of validation they > might require the client to also be willing to do a lot of reconnects > automatically in order to be really affected. > > -Ekr > > [0] And of course in Karthik's attack, the assumption is that the client > would connect to the attack server in any case and so even in an > all HTTPS world, the attacker could shove down arbitrary JS from > his own site. > > >> Still, public key validation remains important for both ECDHE and DHE, a= nd >> essential to prevent insecure resumption-like attacks. >> >> 1. At the end of the first handshake, the finished messages of the >> connections C/A and A/S will be different. >> 2. The outline of the attack rests on the assumption that A might simply >> forward the messages during the second handshake, because all parameters= are >> the same, and here the finished messages for C/A and A/S will consequent= ly >> also be the same. Well, they will be if no renegotiation indication >> extension is included. If it is, this will however be different for C/A = and >> A/S, and hence result in different finished messages after the second >> handshake as well. >> >> >> Yes, which is why the attack requires 3 handshakes not two. By injecting= a >> resumption handshake between 1. and 2. above, the finished messages of C= /A >> and A/S can be made the same. I=E2=80=99d be happy to discuss off-list. >> >> Best, >> Karthik >> >> >> >> Am I missing something obvious? >> >> _______________________________________________ >> 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 > --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Mar 28 08:14:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA001A0919 for ; Fri, 28 Mar 2014 08:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDwva4jVsbBc for ; Fri, 28 Mar 2014 08:14:36 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1EF1A0668 for ; Fri, 28 Mar 2014 08:14:36 -0700 (PDT) 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 s2SFEWDx010258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Mar 2014 11:14:33 -0400 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 s2SEeCsR021401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Mar 2014 10:40:13 -0400 Message-ID: <1396017612.19721.110.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "Salz, Rich" Date: Fri, 28 Mar 2014 15:40:12 +0100 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE833@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE833@USMBX1.msg.corp.akamai.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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OPWEx2xqpC30ag8seXXR3NUe9Jw Cc: "" Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 15:14:38 -0000 On Fri, 2014-03-28 at 10:12 -0400, Salz, Rich wrote: > > The TLS WG charter is pretty clear that the intention isn't to design a completely new protocol but rather to revise TLS, > > and specifically to "place a priority in minimizing gratuitous changes to TLS." > +1. > > It seems to me that there are almost three viewpoints within this WG. With the hope that I'm equally unfair to everyone, I'd summarize them like this: > - Update to modern crypto knowledge to fix bugs, and some modern features and be done > - Make big changes to fix serious problems > - Start over from a clean sheet; "I don't know what it will be, but we'll call it TLS." > I put myself in the first group (except for SNI encryption, which will get a separate post :), could be convinced to support something from the second once it's written down, and am probably not qualified to evaluate anything from the third group (few people are). Interestingly, barring divine intervention, the above list is probably in order of length of time needed, as well. That would seem to indicate that there's room for all three efforts here. This is not my impression of the discussions and the meetings. Eric in the last meetings has presented a list of changes to the protocol that really exceeds the "Update to modern crypto knowledge to fix bugs, and some modern features and be done", (whatever that means). So my understanding is that there will be big changes (e.g., reducing handshake messages, redesign of handshake to encrypt everything) to fix serious and not serious problems (e.g., reducing the round-trips), and the question is whether to do it: 1. within the working group (which is stated to have no crypto expertise). 2. by using external expertise. regards, Nikos From nobody Fri Mar 28 08:25:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49FF1A02DB for ; Fri, 28 Mar 2014 08:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 m9sFkPsVD1U3 for ; Fri, 28 Mar 2014 08:24:59 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 388341A00F9 for ; Fri, 28 Mar 2014 08:24:59 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id s7so3878653lbd.29 for ; Fri, 28 Mar 2014 08:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iwSb3ABn/Rf5Hkdd4Be09zUtmG3RF0Nw/extZAXj+e4=; b=FNg80JxYBsXYaovTQwYy0ql0xDd286HN+nAz2kEuU5cGKZ4nwfbjGhVScYGWd+gGpS OH5KCm5sDQIoWy1t19FffSzqEQ49pRtqC0rt30YG5PuBKiii69yHzhDijdLWx1hhLI02 dsFd+caPNpqv7aT6GK87xfFXEWWruNK3w9/t69MgOWq4TOtA8uy1WO7CAKpk2gavjzMG MIoQaMdRaIytG7UxRC5sprQfeYHtjXr0aIU5JoVKH6MZJ9NL0oGk03UVNDLSBy6yB+bW hbUQzXwKj6OlIWMe16vWbhtqKKN4uM8cmHIBuVYCVWClIjlv+jcQlbaURz8Idhj/lvZ8 6Usg== MIME-Version: 1.0 X-Received: by 10.153.4.134 with SMTP id ce6mr5958481lad.21.1396020296437; Fri, 28 Mar 2014 08:24:56 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.35.131 with HTTP; Fri, 28 Mar 2014 08:24:56 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE833@USMBX1.msg.corp.akamai.com> Date: Fri, 28 Mar 2014 11:24:56 -0400 X-Google-Sender-Auth: p-Uxew4Mk4phr0JGX4DGssEf4Kk Message-ID: From: Adam Langley To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DVaNk-Drq2kyk6gzlDxjgqHa1rE Cc: "" Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 15:25:01 -0000 On Fri, Mar 28, 2014 at 11:01 AM, Watson Ladd wrote: > I think the first issue should be our biggest priority: leave the > handshake largely alone, focus on fixing insecure resumption and the > record layer, removing compression, mandate secure renegotiation, > document 1/N-1 record splitting. All of this needs to be done in TLS > 1.2, and there are drafts for most of it already. I would rather like to see a TLS 1.3 that is a tidying up of 1.2: merging the various RFCs into one, editing and pulling in some of the drafts that are floating around. The more significant changes could be 1.4. Of course that all depends on someone actually doing the work and I might be up for that too. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Fri Mar 28 08:35:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6A81A065A for ; Fri, 28 Mar 2014 08:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SxZKO2FGpiN for ; Fri, 28 Mar 2014 08:35:12 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 219781A02DB for ; Fri, 28 Mar 2014 08:35:11 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id q5so897441wiv.1 for ; Fri, 28 Mar 2014 08:35:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DWVdvH4K6cxWRd65hG9s93OmgdmfLj2td1ADhGQQ66U=; b=WWDdxQE/E+GHUZWVmG5zL3b77eYNLLfJhoJ31iGV8TksoXVIAcJCObXgIZCWKENouO VvtbRl6AEkwk5kfk2MIZV27IgIPkPEq3nKXny+1HU5+eCjaR7za2URYUcB1yZj49hB8/ LEd6PfQLpM0eVGdJReSzoh9rCq2WFvj3kYLLqn0lmQtEDH9vZIM7BuUhQY7Eu5WOjyTI j0wjOs/O/4fhl/XYmEYMR+T8QJliBKlBX4KaJOXT5pB67J6IoQlsSUnQYt9dOQ1gRg8/ oXM167NEjUx6T8u7f5gWbLz+Z4Tf8h2TxM519TpqV+/9N1YkiNINPuIOS9PGpWYQa/4l +niA== X-Gm-Message-State: ALoCoQllkdQPIlKmnpZjoezt2kLLQ8vxZJAmLNYdH8u5JCqJ6fWxJseXu7lvIf2Jz6OViuxVkUtv X-Received: by 10.180.108.199 with SMTP id hm7mr48435467wib.1.1396020909466; Fri, 28 Mar 2014 08:35:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Fri, 28 Mar 2014 08:34:29 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <1396017612.19721.110.camel@dhcp-2-127.brq.redhat.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE833@USMBX1.msg.corp.akamai.com> <1396017612.19721.110.camel@dhcp-2-127.brq.redhat.com> From: Eric Rescorla Date: Fri, 28 Mar 2014 08:34:29 -0700 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=e89a8f3bae5d68833d04f5ac7247 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0tiXNDnBKsEwzDg2ioYcL1ouUWM Cc: "" Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 15:35:15 -0000 --e89a8f3bae5d68833d04f5ac7247 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 28, 2014 at 7:40 AM, Nikos Mavrogiannopoulos wrote: > On Fri, 2014-03-28 at 10:12 -0400, Salz, Rich wrote: > > > The TLS WG charter is pretty clear that the intention isn't to design > a completely new protocol but rather to revise TLS, > > > and specifically to "place a priority in minimizing gratuitous changes > to TLS." > > +1. > > > > It seems to me that there are almost three viewpoints within this WG. > With the hope that I'm equally unfair to everyone, I'd summarize them like > this: > > - Update to modern crypto knowledge to fix bugs, and some modern > features and be done > > - Make big changes to fix serious problems > > - Start over from a clean sheet; "I don't know what it will be, > but we'll call it TLS." > > I put myself in the first group (except for SNI encryption, which will > get a separate post :), could be convinced to support something from the > second once it's written down, and am probably not qualified to evaluate > anything from the third group (few people are). Interestingly, barring > divine intervention, the above list is probably in order of length of time > needed, as well. That would seem to indicate that there's room for all > three efforts here. > > This is not my impression of the discussions and the meetings. Eric in > the last meetings has presented a list of changes to the protocol that > really exceeds the "Update to modern crypto knowledge to fix bugs, and > some modern features and be done", (whatever that means). > > So my understanding is that there will be big changes (e.g., reducing > handshake messages, redesign of handshake to encrypt everything) to fix > serious and not serious problems (e.g., reducing the round-trips), Yes, I think the changes to the handshake we have been discussing probably would fall under #2 in Rich's taxonomy. > and > the question is whether to do it: > 1. within the working group (which is stated to have no crypto > expertise). > 2. by using external expertise. I actually don't think think this is the question, since IETF work is done in WGs and we would reach out (and are reaching out) for external expertise in any case. -Ekr --e89a8f3bae5d68833d04f5ac7247 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 28, 2014 at 7:40 AM, Nikos Mavrogiannopoulos <nmav@redh= at.com> wrote:
On Fri, 2014-03-28 at 10:12 = -0400, Salz, Rich wrote:
> > The TLS WG charter is pretty clear that the intention isn't t= o design a completely new protocol but rather to revise TLS,
> > and specifically to "place a priority in minimizing gratuito= us changes to TLS."
> +1.
>
> It seems to me that there are almost three viewpoints within this WG. = =A0With the hope that I'm equally unfair to everyone, I'd summarize= them like this:
> =A0 =A0 =A0 - Update to modern crypto knowledge to fix bugs, and some = modern features and be done
> =A0 =A0 =A0 - Make big changes to fix serious problems
> =A0 =A0 =A0 - Start over from a clean sheet; "I don't know wh= at it will be, but we'll call it TLS."
> I put myself in the first group (except for SNI encryption, which will= get a separate post :), could be convinced to support something from the s= econd once it's written down, and am probably not qualified to evaluate= anything from the third group (few people are). Interestingly, barring div= ine intervention, the above list is probably in order of length of time nee= ded, as well. That would seem to indicate that there's room for all thr= ee efforts here.

This is not my impression of the discussions and the meetings. Eric i= n
the last meetings has presented a list of changes to the protocol that
really exceeds the "Update to modern crypto knowledge to fix bugs, and=
some modern features and be done", (whatever that means).

So my understanding is that there will be big changes (e.g., reducing
handshake messages, redesign of handshake to encrypt everything) to fix
serious and not serious problems (e.g., reducing the round-trips),

Yes, I think the changes to the handshake we have = been discussing
probably would fall under #2 in Rich's taxono= my.

=A0
and
the question is whether to do it:
1. within the working group (which is stated to have no crypto
expertise).
2. by using external expertise.

I actually = don't think think this is the question, since IETF work is
do= ne in WGs and we would reach out (and are reaching out) for
external expertise in any case.

-Ekr
--e89a8f3bae5d68833d04f5ac7247-- From nobody Fri Mar 28 09:31:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17421A092F for ; Fri, 28 Mar 2014 09:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moSDJL2_QqIw for ; Fri, 28 Mar 2014 09:31:29 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id D04441A00FB for ; Fri, 28 Mar 2014 09:31:28 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jz11so5838831veb.25 for ; Fri, 28 Mar 2014 09:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=qcmeUsnfPnHzqyuYe0vgYu5vZka3A+s066T9C2PKQks=; b=Np67Ty6qaH8sces9CiEHw98EwbyN0GjfNOv5rqiLD4hoZOwmuqg6wY1mnSRd+IX7kx 18RJbqf4TEz/L/pdJB15Rs6HVfq0xfj0EUxP+pTsoqM7H65fzWM/UJEr3piTKQ0RZfxi lU8j7jojRflnz1RRSc9uCgkAolMEqKtFispA/8ZP0b+l2ffFk6D2zgYVAS2+M5yvwg5E 089rTIdSUiTrD5PxuffwsrddaiwesB2QvVBhjO8qOxi9xJXpcMwxhpuHglIN0R/T8MOU aps0OyLK/JqIxQHIbhIHlh72unDANE+ou97dTqvCVaH5omNeD9yygDzBbKZDOPctT4On jepA== MIME-Version: 1.0 X-Received: by 10.220.92.135 with SMTP id r7mr7971793vcm.11.1396024286471; Fri, 28 Mar 2014 09:31:26 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.221.18.70 with HTTP; Fri, 28 Mar 2014 09:31:26 -0700 (PDT) Date: Fri, 28 Mar 2014 09:31:26 -0700 X-Google-Sender-Auth: ajwGlB8ln2m4xqBPqVjMQgxsy4s Message-ID: From: Erik Nygren To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b66f5fbb16bc104f5ad3b58 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d2xnWZbSiHhTRuMjhgacD5RAt54 Subject: [TLS] Does OE really belong in core 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, 28 Mar 2014 16:31:31 -0000 --047d7b66f5fbb16bc104f5ad3b58 Content-Type: text/plain; charset=ISO-8859-1 I was thinking more about one of the post-meeting discussions on the proposed new flows and SNI (and handshake) encryption. One question that jumped to mind is whether or not it is prudent to build features into the core of TLS 1.3 that are vulnerable to active attacks? In particular, if the only way of encrypting the handshake is effectively opportunistic encryption, is it better to not do this at the TLS layer? Having parts of TLS be vulnerable to active attackers seems like it has the potential to make TLS much harder to reason about, especially for implementers and for people trying to understand what security properties it provides (beyond magic security pixie dust). It feels like OE may only belong in layers above or below TLS. At layers below (eg, via tcpcrypt or ipsec), it may be easier to set expectations for using OE in ways that would protect the TLS handshake but without making the properties provided by TLS itself harder to reason about. (On the down-side, this may be harder to implement due to adding extra round-trips and due to the potential for additionally encrypting traffic on yet another layer.) On the layers above TLS (eg, HTTP), it may be easier for applications to reason about the consequences of OE (such as by enforcing an "http" scheme with no visible user behavior change in the cases where no endpoint authentication is performed). At a very minimum, we need to make sure that if there is any OE as part of the TLS 1.3 handshake that there's a very clear distinction between the opportunistic part ends and the where the actual authenticated part begins, with a clear distinction of what is within each and how they are securely glued together (if such is possible). For example, sending actual data during the OE part before the authentication completes seems very dangerous and hard to reason about. I realize that encrypting more of the handshake is a charter item for TLS 1.3, and that there's a general desire to protect against passive monitoring, but it may be worth carefully considering the consequences of adding features to the core of the TLS protocol that are vulnerable by-design to active attacks (rather than addressing this at other layers). Erik --047d7b66f5fbb16bc104f5ad3b58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I was thinking more about one of the post-meetin= g discussions on the proposed new flows and SNI (and handshake) encryption.= =A0 One question that jumped to mind is whether or not it is prudent to bui= ld features into the core of TLS 1.3 that are vulnerable to active attacks?=

In particular, if the only way of encrypting the handshake is effective= ly opportunistic encryption, is it better to not do this at the TLS layer?= =A0 Having parts of TLS be vulnerable to active attackers seems like it has= the potential to make TLS much harder to reason about, especially for impl= ementers and for people trying to understand what security properties it pr= ovides (beyond magic security pixie dust).=A0

It feels like OE may only belong in layers above or below TL= S.=A0 At layers below (eg, via tcpcrypt or ipsec), it may be easier to set = expectations for using OE in ways that would protect the TLS handshake but = without making the properties provided by TLS itself harder to reason about= .=A0 (On the down-side, this may be harder to implement due to adding extra= round-trips and due to the potential for additionally encrypting traffic o= n yet another layer.)=A0 On the layers above TLS (eg, HTTP), it may be easi= er for applications to reason about the consequences of OE (such as by enfo= rcing an "http" scheme with no visible user behavior change in th= e cases where no endpoint authentication is performed).

At a very minimum, we need to make sure that if there is any OE as part= of the TLS 1.3 handshake that there's a very clear distinction between= the opportunistic part ends and the where the actual authenticated part be= gins, with a clear distinction of what is within each and how they are secu= rely glued together (if such is possible).=A0 For example, sending actual d= ata during the OE part before the authentication completes seems very dange= rous and hard to reason about.

I realize that encrypting more of the handshake is a c= harter item for TLS 1.3, and that there's a general desire to protect a= gainst passive monitoring, but it may be worth carefully considering the co= nsequences of adding features to the core of the TLS protocol that are vuln= erable by-design to active attacks (rather than addressing this at other la= yers).

=A0=A0=A0=A0=A0=A0=A0 Erik

--047d7b66f5fbb16bc104f5ad3b58-- From nobody Fri Mar 28 09:35:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815831A092F for ; Fri, 28 Mar 2014 09:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRDGtq1cinTy for ; Fri, 28 Mar 2014 09:35:29 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B78491A00FB for ; Fri, 28 Mar 2014 09:35:29 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 10so3888891ykt.32 for ; Fri, 28 Mar 2014 09:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xxfioOl03tOpN5gQgjCkabjLZWj4EdGwDWZKLABS1pY=; b=Dm2RXLgjfxD3jMIDVz7zgxi0n2lF7gGdcBpsiyfIGRSXG7qGvZGcBlqCW+muWGS6je aSg3okZuzTF5qN0QrQD8ORiC7aQB+gq+6WWMQlAxTkJEinZiDklrvIVq5sh492jGMigp FbBXjiGunOQUPyTjXZm5b+Hd8eQCtW8nDUeIPiT36dOxx4uacWX8wl1zkTNiGR6T40u7 Jwxf0PGrS7BMS6YM+4OIFCgmj2aly+EoOXs7WfMQFVDgfkIl5i/aWbTOlNbotWMtFyly QYptF2z0u9gykikjCcnEOD6mBPNE/BZem/gdma4dewqop7+jsk47YJKzx2LdhyV5bBrG dP1A== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr12824085yhi.4.1396024527496; Fri, 28 Mar 2014 09:35:27 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Fri, 28 Mar 2014 09:35:27 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE833@USMBX1.msg.corp.akamai.com> <1396017612.19721.110.camel@dhcp-2-127.brq.redhat.com> Date: Fri, 28 Mar 2014 12:35:27 -0400 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LjO74Ca42lHR8Yz1lFeTaRggFXA Cc: "" Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 16:35:32 -0000 On Fri, Mar 28, 2014 at 11:34 AM, Eric Rescorla wrote: > > > > On Fri, Mar 28, 2014 at 7:40 AM, Nikos Mavrogiannopoulos > wrote: >> >> On Fri, 2014-03-28 at 10:12 -0400, Salz, Rich wrote: >> > > The TLS WG charter is pretty clear that the intention isn't to design >> > > a completely new protocol but rather to revise TLS, >> > > and specifically to "place a priority in minimizing gratuitous changes >> > > to TLS." >> > +1. >> > >> > It seems to me that there are almost three viewpoints within this WG. >> > With the hope that I'm equally unfair to everyone, I'd summarize them like >> > this: >> > - Update to modern crypto knowledge to fix bugs, and some modern >> > features and be done >> > - Make big changes to fix serious problems >> > - Start over from a clean sheet; "I don't know what it will be, >> > but we'll call it TLS." >> > I put myself in the first group (except for SNI encryption, which will >> > get a separate post :), could be convinced to support something from the >> > second once it's written down, and am probably not qualified to evaluate >> > anything from the third group (few people are). Interestingly, barring >> > divine intervention, the above list is probably in order of length of time >> > needed, as well. That would seem to indicate that there's room for all three >> > efforts here. >> >> This is not my impression of the discussions and the meetings. Eric in >> the last meetings has presented a list of changes to the protocol that >> really exceeds the "Update to modern crypto knowledge to fix bugs, and >> some modern features and be done", (whatever that means). >> >> So my understanding is that there will be big changes (e.g., reducing >> handshake messages, redesign of handshake to encrypt everything) to fix >> serious and not serious problems (e.g., reducing the round-trips), > > > Yes, I think the changes to the handshake we have been discussing > probably would fall under #2 in Rich's taxonomy. But what Rich neglected to point out is that you have to do #1 anyway. The bugs in TLS 1.2 and older versions need fixing. If you end up tying that fix together with a bunch of bigger changes, they won't get fixed because people will (incorrectly) see this as a new version rather than a bundle of necessary fixes with some new features. There is no reason to bundle the record layer/handshake fixes and handshake enhancements together. > > >> >> and >> the question is whether to do it: >> 1. within the working group (which is stated to have no crypto >> expertise). >> 2. by using external expertise. > > > I actually don't think think this is the question, since IETF work is > done in WGs and we would reach out (and are reaching out) for > external expertise in any case. Kenneth Patterson and Peter Gutmann are in the WG. Sincerely, Watson Ladd > > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Mar 28 09:52:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACBD1A0695 for ; Fri, 28 Mar 2014 09:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lDmy25L8-4z for ; Fri, 28 Mar 2014 09:52:27 -0700 (PDT) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id F1CF91A0668 for ; Fri, 28 Mar 2014 09:52:26 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so2889923wes.1 for ; Fri, 28 Mar 2014 09:52:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fLlSGuGZ/XrkQVnNGUkagnf3qkViqdW6S3EwvdKWtP8=; b=Qbn6tp73rnIa+ZYTkPnOX0C07uiWH0JJAfxfp+2kZrDBthc8dtd3VQP83LehCyTFcx 6cHPXkQpaAIj+mJMjqti48KQHPHRCQy8Zn1JZKKhzmSdRzDPz7pqNQNYK1tRuQmbiA3u 5RTpBRy2wBBUoKwLS/LDargjpkb1a9EhH57zWDUa6GkK2XcJojDah4pOSzwY5gD2z0O7 xpV6mZt7xEise1SGnYXv+8okuFOCnC8obFLRu3mDRdkE4wJjF9oa2hDOWNgFgL0kJLP0 Ug+Ii2wEKibf+vKWH3XFrF0mTeJCmimUUdMzww9oHX4XhOpbSh4ftAl0l5f7Jwwr5owL ieSQ== X-Gm-Message-State: ALoCoQkV3ExbD9nY8AQQMXL9rfVML2nTVInJr+V0TDPRq0WM9DgWgpZpgox6YI4QRGUGiU7gVMIe MIME-Version: 1.0 X-Received: by 10.180.19.35 with SMTP id b3mr49173881wie.20.1396025544357; Fri, 28 Mar 2014 09:52:24 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Fri, 28 Mar 2014 09:52:24 -0700 (PDT) X-Originating-IP: [184.23.29.222] In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE833@USMBX1.msg.corp.akamai.com> <1396017612.19721.110.camel@dhcp-2-127.brq.redhat.com> Date: Fri, 28 Mar 2014 09:52:24 -0700 Message-ID: From: Trevor Perrin To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VXURyyd9QGa-augql02yJegUcKM Cc: "" Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 16:52:29 -0000 On Fri, Mar 28, 2014 at 8:34 AM, Eric Rescorla wrote: > > On Fri, Mar 28, 2014 at 7:40 AM, Nikos Mavrogiannopoulos > wrote: >> >> On Fri, 2014-03-28 at 10:12 -0400, Salz, Rich wrote: >> > > The TLS WG charter is pretty clear that the intention isn't to design >> > > a completely new protocol but rather to revise TLS, >> > > and specifically to "place a priority in minimizing gratuitous changes >> > > to TLS." >> > +1. >> > >> > It seems to me that there are almost three viewpoints within this WG. >> > With the hope that I'm equally unfair to everyone, I'd summarize them like >> > this: >> > - Update to modern crypto knowledge to fix bugs, and some modern >> > features and be done >> > - Make big changes to fix serious problems >> > - Start over from a clean sheet; "I don't know what it will be, >> > but we'll call it TLS." ... >> This is not my impression of the discussions and the meetings. Eric in >> the last meetings has presented a list of changes to the protocol that >> really exceeds the "Update to modern crypto knowledge to fix bugs, and >> some modern features and be done", (whatever that means). >> >> So my understanding is that there will be big changes (e.g., reducing >> handshake messages, redesign of handshake to encrypt everything) to fix >> serious and not serious problems (e.g., reducing the round-trips), > > > Yes, I think the changes to the handshake we have been discussing > probably would fall under #2 in Rich's taxonomy. Agreed with Nikos and Eric that the WG (and charter) seemed willing to consider major changes, as evidenced by the interest in Eric's "new flows" draft. If anything, I'm not sure the difference between Rich's #2 and #3 really exists - if we're willing to replace the existing TLS initial and resumption flows with a flexible composition of exchanges based around semi-static public keys, zero-RTT pre-emptive encryption, and anti-replay tokens (Eric's draft) - and revisit the crypto - then we're designing a new protocol, whether we admit it or not. >> and >> the question is whether to do it: >> 1. within the working group (which is stated to have no crypto >> expertise). >> 2. by using external expertise. > > > I actually don't think think this is the question, since IETF work is > done in WGs and we would reach out (and are reaching out) for > external expertise in any case. Don't fully agree with Nikos. For (1), this WG *does* have participation from many cryptographers. For (2), it's true anyone can participate. But Nikos has a point - there are differences in how processes encourage or discourage participation. I think creating a complex protocol by trying to reach consensus on a hundred different points individually will result in a huge volume of complicated, hard-to-follow discussions, which will need to be sorted out at f2f meetings with substantial wrangling and steering from the chairs. So the only people able to fully participate will be those willing to invest hours a day deciphering mailing list threads and trying to "win" discussions, and spend the time and money to attend IETF meetings where the big decisions will be made. In contrast, a process based around alternative proposals makes it much easier to participate by either submitting a proposal or reviewing others. And the range of things being considered becomes much more legible, since once can review a few leading proposals instead of trying to reverse-engineer debates embedded in thousands of mailing list posts. Trevor From nobody Fri Mar 28 12:03:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9711A07F2 for ; Fri, 28 Mar 2014 12:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_sB0sYymNn2 for ; Fri, 28 Mar 2014 12:03:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by ietfa.amsl.com (Postfix) with ESMTP id 840E61A078A for ; Fri, 28 Mar 2014 12:03:30 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) with Microsoft SMTP Server (TLS) id 15.0.898.11; Fri, 28 Mar 2014 19:03:27 +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.0908.008; Fri, 28 Mar 2014 19:03:26 +0000 From: Andrei Popov To: Daniel Kahn Gillmor , Marsh Ray , Martin Thomson Thread-Topic: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) Thread-Index: AQHPShlAQ7PNLxYPxkG9wW1NfjsVj5r1ogCAgADcR4CAAFgTMA== Date: Fri, 28 Mar 2014 19:03:25 +0000 Message-ID: <368f5b8e9f9b49d1b8b1e2600a1b8a49@BL2PR03MB419.namprd03.prod.outlook.com> References: <31dba3a928d145c6835d4bbcfa603354@BY2PR03MB074.namprd03.prod.outlook.com> <5335785F.2070104@fifthhorseman.net> In-Reply-To: <5335785F.2070104@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(377454003)(51704005)(13464003)(189002)(199002)(51444003)(479174003)(98676001)(79102001)(20776003)(63696002)(76482001)(81342001)(49866001)(2656002)(97186001)(97336001)(87266001)(50986001)(90146001)(54316002)(1511001)(47446002)(74662001)(74876001)(51856001)(4396001)(94316002)(80976001)(87936001)(93136001)(92566001)(77982001)(85852003)(74316001)(47736001)(76796001)(33646001)(59766001)(95666003)(19580405001)(19580395003)(69226001)(83322001)(15975445006)(93516002)(81686001)(74366001)(86362001)(85306002)(95416001)(81816001)(74502001)(76576001)(81542001)(31966008)(15202345003)(54356001)(56816005)(74706001)(46102001)(47976001)(94946001)(56776001)(53806001)(65816001)(76786001)(80022001)(83072002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB077; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:B8FFC015.AD1F93C2.6DD23F77.4007880B.202DB; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/enUL1ww3Ct8HGhuSrdp-PFCNqgg Cc: "tls@ietf.org" Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 19:03:33 -0000 PiBkaWQgU0NoYW5uZWwgZXZlciBzdXBwb3J0IGNsYXNzaWMgREhFIHdpdGggUlNBIGF1dGhlbnRp Y2F0aW9uPw0KDQoiV2luZG93cyBSVCA4LjEsIFdpbmRvd3MgOC4xLCBhbmQgV2luZG93cyBTZXJ2 ZXIgMjAxMiBSMiB1cGRhdGUgc3ByaW5nIDIwMTQiIGFkZHMgYSBjb3VwbGUgb2YgREhFX1JTQSBj aXBoZXIgc3VpdGVzOg0KVExTX0RIRV9SU0FfV0lUSF9BRVNfMjU2X0dDTV9TSEEzODQNClRMU19E SEVfUlNBX1dJVEhfQUVTXzEyOF9HQ01fU0hBMjU2DQoNCldpdGhvdXQgdGhpcyB1cGRhdGUsIHNj aGFubmVsIHN1cHBvcnRzIERIRV9EU1MgKGFkbWl0dGVkbHksIG5vdCB0aGUgbW9zdCB3aWRlbHkg dXNlZCBhdXRoKS4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgRGFuaWVsIEthaG4gR2lsbG1vcg0KU2VudDogRnJpZGF5LCBNYXJjaCAyOCwgMjAxNCA2OjI2 IEFNDQpUbzogTWFyc2ggUmF5OyBNYXJ0aW4gVGhvbXNvbg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtUTFNdIE51a2luZyBESEUgaW4gZmF2b3VyIG9mIEVDREhFIChXYXM6IFJlOiBD b25maXJtaW5nIENvbnNlbnN1cyBvbiByZW1vdmluZyBSU0Ega2V5IFRyYW5zcG9ydCBmcm9tIFRM UyAxLjMpDQoNCk9uIDAzLzI3LzIwMTQgMDg6MTcgUE0sIE1hcnNoIFJheSB3cm90ZToNCj4gRnJv bTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dDQo+Pg0K Pj4gT24gMjcgTWFyY2ggMjAxNCAxNjo1NSwgTWFyc2ggUmF5IDxtYXJheUBtaWNyb3NvZnQuY29t PiB3cm90ZToNCj4+PiBGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEFseXNzYSBSb3dhbg0KPj4+Pg0KPj4+PiBTaG93IG9mIGhhbmRzOiB3aG8gKnJl YWxseSogd2FudHMgdG8gZGVwbG95IDIwNDgtYml0IChvciBhYm92ZSkgREhFLCB3aGVuIHRoZXkg Y291bGQgaGF2ZSBjdXJ2ZTI1NTE5IGluc3RlYWQ/DQo+Pj4NCj4+PiBUaGUgZ2VuZXJhbCBjb25z ZW5zdXMgYXQgTWljcm9zb2Z0IGlzIHRoYXQgd2UgbGlrZSBFQ0RIRSBtdWNoIGJldHRlciB0aGFu IHRoZSBjbGFzc2ljIERIRS4NCj4+DQo+PiBJIHRoaW5rIHRoYXQgdGhpcyBpcyB0aGUgZ2VuZXJh bCB0cmVuZCwgYnV0IGlzIGl0IHNvIGJhZCB0aGF0IHlvdSB3b3VsZCB3YW50IHRvIHByb2hpYml0 IERIRT8NCj4gDQo+IEhpc3RvcmljYWxseSB3ZSBoYXZlIG9wdGVkIHRvIHByb3ZpZGUgRUNESEUg KmluIHBsYWNlIG9mKiBjbGFzc2ljIERIRS4NCg0KZGlkIFNDaGFubmVsIGV2ZXIgc3VwcG9ydCBj bGFzc2ljIERIRSB3aXRoIFJTQSBhdXRoZW50aWNhdGlvbj8NCg0KIGh0dHA6Ly9tc2RuLm1pY3Jv c29mdC5jb20vZW4tdXMvbGlicmFyeS93aW5kb3dzL2Rlc2t0b3AvYWEzODA1MTIlMjh2PXZzLjg1 JTI5LmFzcHgNCg0Kc3VnZ2VzdHMgdGhhdCBYUCBhbmQgd2luMjAwMyAod2hpY2gsIGFmYWljdCwg d2VyZSB3aGF0IGltbWVkaWF0ZWx5IHByZWNlZGVkIHZpc3RhKSBkb2VzIG5vdCBoYXZlIERIRS4g IFNvIGl0IGxvb2tzIGxpa2UgRUNESEUgd2FzIGp1c3QgYWRkZWQsIGJ1dCAiY2xhc3NpYyBESEUi IHdhc24ndCBpbiBTQ2hhbm5lbCBpbiB0aGUgZmlyc3QgcGxhY2UsIHdoaWNoIGRvZXNuJ3Qgc291 bmQgbGlrZSBFQ0RIRSBpcyAiaW4gcGxhY2Ugb2YiIERIRSB0byBtZS4NCg0Kb3IgYW0gaSBtaXNy ZWFkaW5nIHRoZSBkb2N1bWVudGF0aW9uPw0KDQoJLS1ka2cNCg0K From nobody Fri Mar 28 12:53:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A846E1A06CD; Fri, 28 Mar 2014 12:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agoZ_n8q0yuy; Fri, 28 Mar 2014 12:53:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D61B1A01D8; Fri, 28 Mar 2014 12:53:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> Date: Fri, 28 Mar 2014 12:53:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HeqhBjn4Bw9LGS73yij1T05a08o Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-pwd-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 19:53:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Secure Password Ciphersuites for Transport Layer Security (TLS) Authors : Dan Harkins Dave Halasz Filename : draft-ietf-tls-pwd-04.txt Pages : 35 Date : 2014-03-28 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-pwd-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 28 12:55:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D096A1A0764 for ; Fri, 28 Mar 2014 12:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8Hyjj3Yy17y for ; Fri, 28 Mar 2014 12:55:30 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC1D1A0732 for ; Fri, 28 Mar 2014 12:55:30 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2SJtQUK013322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Mar 2014 12:55:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Fri, 28 Mar 2014 12:55:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <14B8077B-BDED-46B3-B304-80251D4349BF@vpnc.org> References: <5334C8A8.2020906@streamsec.se> To: Eric Rescorla X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8EWW9WRcM48oxJFCo8ogMM-pOK0 Cc: "tls@ietf.org" Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 19:55:31 -0000 As a point of reference, IKE has done well with standardized groups, and = basically no one uses non-standard groups. It's not clear why TLS would = be any different, given that it is the same "client offers many, server = picks one" model. --Paul Hoffman=20= From nobody Fri Mar 28 13:11:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057CD1A0344 for ; Fri, 28 Mar 2014 13:11:31 -0700 (PDT) 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 PrQ__DpAhJ0p for ; Fri, 28 Mar 2014 13:11:24 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB101A0303 for ; Fri, 28 Mar 2014 13:11:24 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id BCE50A888012; Fri, 28 Mar 2014 13:11:21 -0700 (PDT) Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 28 Mar 2014 13:11:22 -0700 (PDT) Message-ID: <843608f469ebd386b9ab547673d6d444.squirrel@www.trepanning.net> In-Reply-To: <532C5867.2050704@gridmerge.com> References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <532B9B65.4030708@gmail.com> <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com> <532C5867.2050704@gridmerge.com> Date: Fri, 28 Mar 2014 13:11:22 -0700 (PDT) From: "Dan Harkins" To: robert.cragie@gridmerge.com 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Nbajcc-d0QU_To7bJTfQ6HOoSKI Cc: "tls@ietf.org" Subject: Re: [TLS] bootstrapping of constrained devices X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Mar 2014 20:11:31 -0000 Hi Robert, On Fri, March 21, 2014 8:19 am, Robert Cragie wrote: > Hi Rene, > > There is certainly a place for device certificates but they are > generally quite expensive in terms of the infrastructure needed to > support them as Michael points out. And they only allow for an authenticated statement that the thing is a particular thing from a particular manufacturer. Not that it is _your_ thing. > There are no specific links I can point to but the use case is using > relatively short codes which are put into e.g. a home router through a > web interface to provide steering, a basis for authenticating another > device onto the network and a secure channel for delivery of > configuration/bootstrapping information. WPS PIN is an example of this > (notwithstanding its implementational flaws). Using TLS/DTLS as a basis > provides the possibility of reuse at the application layer, which is a > bonus for the relatively constrained devices generally considered to be > in use in the IoT. Yes, WPS PIN is horribly broken and should be avoided. A TLS PAKE like TLS-SRP or TLS-pwd would work for this use case. Also, usable certificate can be obtained by something like EST using a TLS PAKE or a manufacturing certificate plus a whitelist of some sort. Dan. > Robert > > On 21/03/2014 12:26 PM, Michael Sweet wrote: >> Rene, >> >> Installing device certificates during manufacturing is not a simple >> process - the factory would need to act as a CA or would need to have >> a supply of certificates that matches whatever identifiers are used by >> the devices. Not to mention how you'd manage revocation if the root >> was compromised... >> >> >> On Mar 20, 2014, at 9:52 PM, Rene Struik > > wrote: >> >>> Hi Robert: >>> >>> Wouldn't it be much easier to embed device certificates with >>> constrained devices at manufacturing? This may do away with need to >>> store info that is not public on servers. >>> >>> If you could provide some links to discussions in "IoT community >>> groups" interested in this, that would help. >>> >>> Best regards, Rene >>> >>> == >>> There is a lot of interest in the IoT community in using some form of >>> PAKE in conjunction with DTLS (or TLS with EAP) for authenticating >>> commissioning/bootstrapping of IoT devices onto IoT networks >>> >>> On 3/20/2014 1:21 PM, Robert Cragie wrote: >>>> >>>> It should be remembered that TLS is used in places other than web >>>> browsers - the existence of the DICE WG is testament to this. There >>>> is a lot of interest in the IoT community in using some form of PAKE >>>> in conjunction with DTLS (or TLS with EAP) for authenticating >>>> commissioning/bootstrapping of IoT devices onto IoT networks. I >>>> realise this is different to the original proposition in this thread >>>> but wanted to draw this to the attention of the WG nevertheless. >>>> >>>> Robert >>>> >>>> On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" >>> > wrote: >>>> >>>> On 03/20/2014 12:18 PM, Paul Hoffman wrote: >>>> > As an important note, you did not define "we" above. A few >>>> possible expansions would be: >>>> > >>>> > - The TLS WG, where this thread currently lives, does not get >>>> to define Web UI without a charter change. >>>> > >>>> > - The HTTPbis WG has not asked the TLS WG to take over this >>>> work, nor has it embraced anything like it. >>>> > >>>> > - The IETF doesn't do this kind of work as a whole body. >>>> > >>>> > - The IAB (of which none of us are part of the "we") might >>>> take the topic on and suggest ways which the IETF might do the >>>> work. >>>> >>>> yep, thanks for the clarification. I actually meant "we" in the >>>> broad >>>> sense of "the community of people who care about making >>>> communications >>>> on the web more secure", which includes groups you didn't even >>>> mention >>>> above, like web site designers, systems administrators, etc. >>>> >>>> It's still on-topic here (despite the broad scope implied above) >>>> because >>>> the TLS WG does have a role to play, by considering the merits of >>>> proposals like http://tools.ietf.org/html/draft-thomson-tls-care, >>>> as >>>> well as considering alternatives that deal with this particular >>>> use case. >>>> >>>> >> option (A) is seriously hard, maybe impossible given the >>>> state of the >>>> >> web. option (B) is terrible. >>>> > >>>> > Exactly right, for any value of "we". >>>> >>>> :( >>>> >>>> --dkg >>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >>> -- >>> email:rstruik.ext@gmail.com | Skype: rstruik >>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>> _______________________________________________ >>> 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 > From nobody Fri Mar 28 13:29:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFCD1A0767 for ; Fri, 28 Mar 2014 13:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGXhikI76la4 for ; Fri, 28 Mar 2014 13:29:23 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB941A0716 for ; Fri, 28 Mar 2014 13:29:23 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi5so1159163wib.17 for ; Fri, 28 Mar 2014 13:29:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mRRgCpgkC3GCOEccidDEmzCRlUppQWZw7Cecj38UCCg=; b=IzdGQEAErruBpzL4wDlEYNxzj8YEAuRCD8ZCxi+XKABI/ATZeP+6QstSjwAnzBtIxM dl5eV8O3DOvQXR5rxsCWj2uZni2jcmOHuscGsAKEQyfDaiBbCuAoHusOD0Frx8fskn8c mQHk+GTFI7JdE9dW+uFJOvvQAfusXc1cgJU/zKIzwUo02WMVxsHvle2T0+A289Bv8JO3 KBupw5asCzHKGRDaxJunbW1C/seF+U8yYTrmAC2uEEcwZa1h7rtY4xvVHu9xusKj+7yL rfXLPQ/4hrObN4dLnfSXhJaX7fGqxj0+3W3k0Rs9NZQY+vrByT7y/cki+aOiqYX2FVoZ DUWA== X-Gm-Message-State: ALoCoQmk5KUdHd8/6ncCfI4am2bLNxO/zzAgeZFsx4ZsWBW2En2I2Q97xnpwigxVONSGhhPRP0PD X-Received: by 10.194.238.231 with SMTP id vn7mr121486wjc.76.1396038560325; Fri, 28 Mar 2014 13:29:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Fri, 28 Mar 2014 13:28:40 -0700 (PDT) X-Originating-IP: [63.245.221.34] In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE833@USMBX1.msg.corp.akamai.com> <1396017612.19721.110.camel@dhcp-2-127.brq.redhat.com> From: Eric Rescorla Date: Fri, 28 Mar 2014 13:28:40 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=089e01493d607b354c04f5b08e9a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z01DcIpnKHCYCQ4SLH__UAQo1z0 Cc: "" Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 20:29:25 -0000 --089e01493d607b354c04f5b08e9a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 28, 2014 at 9:35 AM, Watson Ladd wrote: > On Fri, Mar 28, 2014 at 11:34 AM, Eric Rescorla wrote: > >> and > >> the question is whether to do it: > >> 1. within the working group (which is stated to have no crypto > >> expertise). > >> 2. by using external expertise. > > > > > > I actually don't think think this is the question, since IETF work is > > done in WGs and we would reach out (and are reaching out) for > > external expertise in any case. > > Kenneth Patterson and Peter Gutmann are in the WG. > My bad! I certainly didn't mean to suggest that we didn't have anyone in the WG with cryptographic expertise. We also have Uri Blumenthal, Hugo Krawczyk (from time to time), David McGrew, Marsh Ray, Hovav Shacham, and a bunch of other people I apologize to in advance for not mentioning. -Ekr --089e01493d607b354c04f5b08e9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 28, 2014 at 9:35 AM, Watson Ladd <watsonbladd@gmail.com>= ; wrote:
On F= ri, Mar 28, 2014 at 11:34 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>> and
>> the question is whether to do it:
>> 1. within the working group (which is stated to have no crypto
>> expertise).
>> 2. by using external expertise.
>
>
> I actually don't think think this is the question, since IETF work= is
> done in WGs and we would reach out (and are reaching out) for
> external expertise in any case.

Kenneth Patterson and Peter Gutmann are in the WG.

My bad! I certainly didn't mean to suggest that we di= dn't have anyone in the
WG with cryptographic expertise. We a= lso have Uri Blumenthal, Hugo Krawczyk (from time to time), David McGrew, M= arsh Ray, Hovav Shacham, and a bunch of other people I apologize to in adva= nce for not mentioning.

-Ekr

--089e01493d607b354c04f5b08e9a-- From nobody Fri Mar 28 13:56:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906D51A0732 for ; Fri, 28 Mar 2014 13:56:10 -0700 (PDT) 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 Adi0SU8v2bl6 for ; Fri, 28 Mar 2014 13:56:09 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 279391A06F8 for ; Fri, 28 Mar 2014 13:56:09 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9744EA888012; Fri, 28 Mar 2014 13:56:06 -0700 (PDT) Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 28 Mar 2014 13:56:07 -0700 (PDT) Message-ID: <83ccf2bb3d34687d86ed93be2cfddde6.squirrel@www.trepanning.net> In-Reply-To: <1396009251.19721.76.camel@dhcp-2-127.brq.redhat.com> References: <9A043F3CF02CD34C8E74AC1594475C7372394B5F@uxcn10-6.UoA.auckland.ac.nz> <5335581D.3020608@cs.tcd.ie> <1396009251.19721.76.camel@dhcp-2-127.brq.redhat.com> Date: Fri, 28 Mar 2014 13:56:07 -0700 (PDT) From: "Dan Harkins" To: "Nikos Mavrogiannopoulos" 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3hmLmDT3ePJNtKe8ELHBRLX0Opk Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 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, 28 Mar 2014 20:56:10 -0000 On Fri, March 28, 2014 5:20 am, Nikos Mavrogiannopoulos wrote: > On Fri, 2014-03-28 at 11:08 +0000, Stephen Farrell wrote: >> Peter, >> >> On 03/28/2014 03:32 AM, Peter Gutmann wrote: >> > I haven't said much so far because it seems the 1.3 effort is making >> > steady progress towards the design-by-committee mess that make >> IKEv1/IPsec >> > such a winner, >> >> I'm sure others who were more involved will correct me, >> but wasn't the IKEv1 fun in large part caused by not >> being able to pick a winner from not-hugely-different >> competing proposals, with a sprinkling of not easily >> handled personalities and other competing interests >> involved? > > Yes, but I don't think that we can deduct from the issue that > competition is bad. I don't know what the details where in the case you > describe, and whether the author was justified for refusing changes, but > I think that a working group can make clear that any accepted solution > will be improved during the WG process. > > Competition has worked for the TLS protocol, as SSL 3.0 was not product > of IETF, but rather the result of competition between SSL from Netscape > and PCT by Microsoft, and for its time it was state of the art. The > contribution of IETF was minor changes to SSL 3.0 to obtain TLS 1.0 and > later by fixing open issues. The problems with IKEv1 had nothing to do with competition and everything to do with a naive belief that it was possible to satisfy everyone. IMO, the author was not justified for refusing changes. I remember a presentation in IETF 34 or 35 (forget which) in which Hugo Krawczyk presented very reasonable changes to Photuris that Bill Simpson refused to entertain. That was, in my view, the beginning of the end. The difference between SKIP and ISAKMP/IKE was actually profound. Key management with SKIP was integrated with the data being sent and the notion of an IPsec SA was kind of muddied. IKE was more like Photuris in that respect as a separate key management protocol for creating IPsec SAs. There was a competition and choice made. Then the problems started with contradicting "requirements" from vocal and opinionated people-- need keys to be authenticated not just identities and also we need identity protection, etc-- that ended up with option being piled on top of option creating a mess. Competition worked in the IPsec WG and it can work in the TLS WG too. The "winner" just needs to be forceful in saying no to people and the chairs have to call consensus and move the group along when decisions are made. Dan. From nobody Fri Mar 28 14:49:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC5B1A06C7 for ; Fri, 28 Mar 2014 14:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 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, 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 z8IMO6bRFyZ3 for ; Fri, 28 Mar 2014 14:49:19 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 14E921A03BB for ; Fri, 28 Mar 2014 14:49:18 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 9so4251514ykp.29 for ; Fri, 28 Mar 2014 14:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=eorsUm2nHntABhOC348o+I1YXyt7MXp6PUtCL2JPGtI=; b=v5l5OvJybESZ0CNT9YOCxUdP2D9mIvMWfBmsFc6CSwnPLWZs2IgDF2C+5QfJzfAYuV 9e0VUUa0qEJjdO0qKfimW15YFaP2Y7/b2YAOVgwHxFJfErB5lGYy3903UPjU2dzOFQf/ 9hc3jkfD0AnvUS+ASr8QlVBB0/6cxDCHQqgLOEBPIJbBIVe8mKomImSXweGD/JIBuJlU 6MVevis80JqYlGD7sT5DFtWHRL6ZefP0S9U6RRc8OaiBsGKr4/pvkpQriXyDZaPlwej/ aMns91wrrc57FgxSkNflB+tfepZPVOtraep34Jj7pZxAIP4KlGiMYfD5pk+ef3LrlDRG 486g== MIME-Version: 1.0 X-Received: by 10.236.119.99 with SMTP id m63mr14760811yhh.65.1396043356737; Fri, 28 Mar 2014 14:49:16 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Fri, 28 Mar 2014 14:49:16 -0700 (PDT) In-Reply-To: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> References: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> Date: Fri, 28 Mar 2014 17:49:16 -0400 Message-ID: From: Watson Ladd Cc: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ndmRKAUpJ6BJjjdgJeGGp_W7cUQ Subject: Re: [TLS] I-D Action: draft-ietf-tls-pwd-04.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, 28 Mar 2014 21:49:20 -0000 On Fri, Mar 28, 2014 at 3:53 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security Working Group of the IETF. > > Title : Secure Password Ciphersuites for Transport Layer Security (TLS) > Authors : Dan Harkins > Dave Halasz > Filename : draft-ietf-tls-pwd-04.txt > Pages : 35 > Date : 2014-03-28 Why should we trust this PAKE? I've got only partial results in this direction, but they are not sufficient for me to adopt it when better validated alternatives exist like those based on distrustful MPC. Sincerely, Watson Ladd From nobody Fri Mar 28 15:55:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A775E1A06D8 for ; Fri, 28 Mar 2014 15:55:31 -0700 (PDT) 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 G5ru2idGUMFY for ; Fri, 28 Mar 2014 15:55:30 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 46C901A03CF for ; Fri, 28 Mar 2014 15:55:30 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 95012A888012; Fri, 28 Mar 2014 15:55:27 -0700 (PDT) Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 28 Mar 2014 15:55:28 -0700 (PDT) Message-ID: In-Reply-To: References: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> Date: Fri, 28 Mar 2014 15:55:28 -0700 (PDT) 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6VufyrGbl4q_SOmDOC27kUREvHA Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-pwd-04.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, 28 Mar 2014 22:55:31 -0000 On Fri, March 28, 2014 2:49 pm, Watson Ladd wrote: > On Fri, Mar 28, 2014 at 3:53 PM, wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Transport Layer Security Working Group >> of the IETF. >> >> Title : Secure Password Ciphersuites for Transport >> Layer Security (TLS) >> Authors : Dan Harkins >> Dave Halasz >> Filename : draft-ietf-tls-pwd-04.txt >> Pages : 35 >> Date : 2014-03-28 > > Why should we trust this PAKE? I've got only partial results in this > direction, but they are not sufficient for me to adopt it when better > validated alternatives exist like those based on distrustful MPC. I'm not sure what you mean by "we" but it got quite a bit of review in CFRG and that resulted in fixing the only real technical issue brought up: potential for a side-channel attack. Scott Fluhrer came up with a way to do a random blinding of a value when checking whether its a quadratic residue that effectively addresses that concern. These ciphersuites are drop-in replacements for things like PSK ciphersuites, not for popular ones used in browsers. In fact, I agree with several on this list who are pointing out that using a PAKE in a browser is not a good idea. If you're happy doing cert-based TLS, or happy with HTTP Digest authentication (or whatever) then these are not for you. But the entirety of networking is not "the web" and these ciphersuites work well with some specific use cases (see the draft). regards, Dan. From nobody Fri Mar 28 16:35:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D701A03DE for ; Fri, 28 Mar 2014 16:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO-CdCAchP8L for ; Fri, 28 Mar 2014 16:35:08 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E458F1A03DA for ; Fri, 28 Mar 2014 16:35:07 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 9so4255490ykp.15 for ; Fri, 28 Mar 2014 16:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Huwybris3PBHjFmsL2PSLZIqJHqoSq32sMeHkZmSNXg=; b=B/xEiVLZEHUMIOsX7jPQvLyfRIHvJcNuO0ZKahMtb0q5B0nQemgND2Fw4B7bxQ7JPX 5g9nlKP60za94bTh1ICnkmdE0+466SvlLXrFytW5xuFxCACe9A2t0OvHv+hUr20ushfv S2+972nGN+nebvGDxEgzk7Upq5L48tYiEex+C+JmUhAUvDW1yQ+EkRXMtpxH++5A3E4m T4IplQ1Yj26Clcy565Kq/WlpL3Nq1teKgHzzb0VAI5GvGptGfxi4z4+QJ9r6gKT+ucjh fia2HCnIub9j0wSEPdNl22jn+jA/u+1YH6fqYpSFx3RgNrMfbECTLLPFRGmFbRHrA2DC Qd4Q== MIME-Version: 1.0 X-Received: by 10.236.86.226 with SMTP id w62mr15592908yhe.94.1396049705219; Fri, 28 Mar 2014 16:35:05 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Fri, 28 Mar 2014 16:35:05 -0700 (PDT) In-Reply-To: References: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> Date: Fri, 28 Mar 2014 19:35:05 -0400 Message-ID: From: Watson Ladd To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JcqDeZlFMQLdrZEc6hxNm-WMW2Y Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-pwd-04.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, 28 Mar 2014 23:35:10 -0000 On Fri, Mar 28, 2014 at 6:55 PM, Dan Harkins wrote: > > On Fri, March 28, 2014 2:49 pm, Watson Ladd wrote: >> On Fri, Mar 28, 2014 at 3:53 PM, wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Transport Layer Security Working Group >>> of the IETF. >>> >>> Title : Secure Password Ciphersuites for Transport >>> Layer Security (TLS) >>> Authors : Dan Harkins >>> Dave Halasz >>> Filename : draft-ietf-tls-pwd-04.txt >>> Pages : 35 >>> Date : 2014-03-28 >> >> Why should we trust this PAKE? I've got only partial results in this >> direction, but they are not sufficient for me to adopt it when better >> validated alternatives exist like those based on distrustful MPC. > > I'm not sure what you mean by "we" but it got quite a bit of review > in CFRG and that resulted in fixing the only real technical issue brought > up: potential for a side-channel attack. Scott Fluhrer came up with a > way to do a random blinding of a value when checking whether its a > quadratic residue that effectively addresses that concern. "We didn't break it in the four months we've looked at it" is not a good enough reason. Given that the experts you have consulted have expressed doubts about ever determining its security, I'm inclined to be rather more suspicious of it. During the last half of those two months I was trying to show it would work. The best I can do is reduce it to the two person case, but I can't get it to anything computational. > > These ciphersuites are drop-in replacements for things like PSK > ciphersuites, not for popular ones used in browsers. In fact, I agree > with several on this list who are pointing out that using a PAKE in a > browser is not a good idea. Why is a multi-party computation ala Socialist Millionaire's protocol in OTR not feasible? That establishes a secure channel based on a password shared on both ends in a way that is provably secure. Aug-PAKE can easily be made to work symmetrically: why can't you use that? There are standard models for PAKE security. Does Dragonfly work in them? It clearly requires the ROM: is that enough? You're asking this WG to approve adding a new cryptographic protocol to TLS with dubious justifications, in fact nonexistent, of security, when a well-studied body of knowledge on this problem exists. There is a compelling case for a PAKE: there is not a compelling case for Dragonfly. Sincerely, Watson Ladd > > If you're happy doing cert-based TLS, or happy with HTTP Digest > authentication (or whatever) then these are not for you. But the entirety > of networking is not "the web" and these ciphersuites work well with > some specific use cases (see the draft). > > regards, > > Dan. > > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Mar 28 17:07:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BF81A03F7 for ; Fri, 28 Mar 2014 17:07:46 -0700 (PDT) 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 G2xvxwJca4v4 for ; Fri, 28 Mar 2014 17:07:43 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 862A41A03EB for ; Fri, 28 Mar 2014 17:07:43 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0A037A888012; Fri, 28 Mar 2014 17:07:41 -0700 (PDT) Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 28 Mar 2014 17:07:41 -0700 (PDT) Message-ID: In-Reply-To: References: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> Date: Fri, 28 Mar 2014 17:07:41 -0700 (PDT) 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F9I9lySRGUvr-nVU7ywT2u9hmDA Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-pwd-04.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: Sat, 29 Mar 2014 00:07:47 -0000 On Fri, March 28, 2014 4:35 pm, Watson Ladd wrote: > On Fri, Mar 28, 2014 at 6:55 PM, Dan Harkins wrote: >> >> On Fri, March 28, 2014 2:49 pm, Watson Ladd wrote: >>> On Fri, Mar 28, 2014 at 3:53 PM, wrote: >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Transport Layer Security Working >>>> Group >>>> of the IETF. >>>> >>>> Title : Secure Password Ciphersuites for Transport >>>> Layer Security (TLS) >>>> Authors : Dan Harkins >>>> Dave Halasz >>>> Filename : draft-ietf-tls-pwd-04.txt >>>> Pages : 35 >>>> Date : 2014-03-28 >>> >>> Why should we trust this PAKE? I've got only partial results in this >>> direction, but they are not sufficient for me to adopt it when better >>> validated alternatives exist like those based on distrustful MPC. >> >> I'm not sure what you mean by "we" but it got quite a bit of review >> in CFRG and that resulted in fixing the only real technical issue >> brought >> up: potential for a side-channel attack. Scott Fluhrer came up with a >> way to do a random blinding of a value when checking whether its a >> quadratic residue that effectively addresses that concern. > > "We didn't break it in the four months we've looked at it" is not a > good enough reason. > Given that the experts you have consulted have expressed doubts about > ever determining its security, I'm inclined to be rather more > suspicious of it. It's been more like 2 years, but nevertheless, your complaint is a lack of formal security proof. But that has never been a requirement for a draft in a WG in the Security Area, or any area for that matter, of the IETF. > During the last half of those two months I was trying to show it would > work. The best I can do is reduce it to the two person case, but I > can't get it to anything computational. What a drag, I was hoping you'd come up with something. >> These ciphersuites are drop-in replacements for things like PSK >> ciphersuites, not for popular ones used in browsers. In fact, I agree >> with several on this list who are pointing out that using a PAKE in a >> browser is not a good idea. > > Why is a multi-party computation ala Socialist Millionaire's protocol > in OTR not feasible? That establishes a secure channel based on a > password shared on both ends in a way that is provably secure. > Aug-PAKE can easily be made to work symmetrically: why can't you use > that? There is no draft specifying a multi-party computation ala the Socialist Millionaire's protocol in TLS, much less one that is as mature as TLS-pwd. Aug-PAKE doesn't work in TLS, as shown by draft-shin-tls-augpake-- what's conveyed in the ClientKeyExchange structure since the client's contribution has been overloaded into the ClientHello? Basically, the client must initiate in Aug-PAKE and that forces a square peg into a round hole, or introduces extra rounds. We have gone over this before, but it takes years to get a draft in the state necessary to become an RFC. You said it took more like 30 minutes, but I'm sure you'd like to reevaluate that after your experience with the CFRG I-D you have been writing. In any event, the only draft _right now_ that satisfies the requirements is TLS-pwd. > There are standard models for PAKE security. Does Dragonfly work in > them? It clearly requires the ROM: is that enough? > > You're asking this WG to approve adding a new cryptographic protocol > to TLS with dubious justifications, in fact nonexistent, of security, > when a well-studied body of knowledge on this problem exists. There is > a compelling case for a PAKE: there is not a compelling case for > Dragonfly. The same WG that approved of RFC 4279, a Standards Track RFC that did not have a proof in the ROM because it has no security. Yes, that same WG. I'm proposing a set of robust and misuse-resistant replacements for the RFC 4279 ciphersuites. regards, Dan. > Sincerely, > Watson Ladd >> >> If you're happy doing cert-based TLS, or happy with HTTP Digest >> authentication (or whatever) then these are not for you. But the >> entirety >> of networking is not "the web" and these ciphersuites work well with >> some specific use cases (see the draft). >> >> regards, >> >> Dan. >> >> > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > From nobody Fri Mar 28 18:22:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EC51A076A for ; Fri, 28 Mar 2014 18:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJPJv6Pc_g52 for ; Fri, 28 Mar 2014 18:22:33 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 563DF1A075A for ; Fri, 28 Mar 2014 18:22:33 -0700 (PDT) Received: from [192.168.13.159] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 5A4C3F984; Fri, 28 Mar 2014 21:22:29 -0400 (EDT) Message-ID: <53362055.3050304@fifthhorseman.net> Date: Fri, 28 Mar 2014 21:22:29 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: Santosh Chokhani , "mrex@sap.com" , "Joseph Salowey (jsalowey)" References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <4262AC0DB9856847A2D00EF817E81139174CF2@scygexch10.cygnacom.com> In-Reply-To: <4262AC0DB9856847A2D00EF817E81139174CF2@scygexch10.cygnacom.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KiNFagDW53QJ6ouSsw3hE7eTgUiisKCHp" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RaPV4PPKvPu4akVffNdpgoiLTd4 Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 01:22:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KiNFagDW53QJ6ouSsw3hE7eTgUiisKCHp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/26/2014 07:25 PM, Santosh Chokhani wrote: > While I agree with most of what you say including some benefits of RSA,= the DHE parameter verification by the client while desirable is not a ge= nuine security threat. A rogue server has many other ways to compromise = the exchange, The recent https://secure-resumption.com/ showed that one malicious server (which a victim deliberately connects to) could use a weak discrete log DHE group to force a client doing client-cert authentication into signing a pre-master secret of the server operator's choice. The malicious server operator could then replay that pre-master secret to another server (in a non-DHE ciphersuite), creating two sessions with the same session id, master secret, and connection keys (they call this an "Unknown key share attack" or UKS). They didn't find a way to exploit a UKS directly without taking advantage of other flaws in the TLS protocol, but if the option of using a bad group hadn't been there, clients using DHE ciphersuites would have been resistant to the attacks they did find. So permitting the use of an arbitrary DL DH group whose structure is too expensive for the client to verify is something we should try to avoid. --dkg --KiNFagDW53QJ6ouSsw3hE7eTgUiisKCHp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTNiBVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcaJEQALofROnMK7tpvR/YrX4g3FHh VISW1fo0NWebpqqgvXrd7bWoW1w7iTGOi+lLxC5r6QslKpCR9BnvixUJ1Zxkt80n 7ECbaRcnx7ODDkdmFYnkpJBU53MwsL9QiF1rximTJTBSwZhXxtu35aAD+9eXS2/z LU/v/16i180h0SkL0S3OTHkI7jezJ4x2lMJtWYHR281ZoOE1CZYJkhIGdnx8qZDv EBaZTmAnC9CibkgRFA9xH/FCeH8sIo++7eaS5IQ5Fb2jcH+Cb41b3JZFnY5XVpH9 lUuNa7PUrOdAtdOB8vucgeKBBrps37xbXvK44CeB3+b7oV4GZAwJJEcp2Z+Fui9f CWQTfs1M5T6qFPiqC2LVD0s1QruhTPcZV/Sj1b8h+xl2ZKZJV5nhR19EqlTUqPr+ UiB7DSnOQT0FsJjkODlYXDu1Hl5qw3VzzsTQwG4gSuQ88J/mun78cIM5K/0N71rk UtACvZJf8X95ajl6qlE8Gj6UqYYaAUzN6pR7TB2ezdrd4g4635BZyF9gkUjgGrfw g+jd5A/Kb6gdwdWbthDukof3vv0tH1ahDZpjE9InsO3iUGCVo3Alj+NQEsfYmnPu f+RFgL3p1S1v+Ffx/MToGQ6sMtV0MJ7vESHz/oLf80JpoMPemd0z5KQ4+NpetxuA 7xd/DVT6LEFu68moh+zD =/oGt -----END PGP SIGNATURE----- --KiNFagDW53QJ6ouSsw3hE7eTgUiisKCHp-- From nobody Fri Mar 28 18:33:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D882E1A0755 for ; Fri, 28 Mar 2014 18:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3] 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 sMMybQq547yE for ; Fri, 28 Mar 2014 18:33:42 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CFF641A040F for ; Fri, 28 Mar 2014 18:33:42 -0700 (PDT) Received: from [192.168.13.159] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 9A177F984; Fri, 28 Mar 2014 21:33:39 -0400 (EDT) Message-ID: <533622F3.2090406@fifthhorseman.net> Date: Fri, 28 Mar 2014 21:33:39 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: =?UTF-8?B?SGFubm8gQsO2Y2s=?= , tls@ietf.org References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> In-Reply-To: <20140327095527.5335c7fa@hboeck.de> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="e9VCccSRitrtswUCU3aupKQ1xH2EsRKGS" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LzxmcBSbgKrz0KQMbiQGThI2Pn0 Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 01:33:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --e9VCccSRitrtswUCU3aupKQ1xH2EsRKGS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/27/2014 04:55 AM, Hanno B=C3=B6ck wrote: > Appart from the other issues, I think it would make a lot of sense to > change DHE handling in TLS 1.3 away from "server can have arbitrary > parameters". I agree with this. > The authors of the triple handshake attack have proposed having a set > of "known good" parameters and I think this is the way to go for TLS > 1.3 and DHE. It's probably enough to say "we define a 2048 and a 4096 > DH parameter set with tested and known primes" and allow the option to > easily define more if there ever is a need to say "we need 8192 bit DHE= > now". I've submitted an initial stab at a proposal for negotiated discrete log diffie-hellman ciphersuites: http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-00 Please send criticism and suggestions. I've selected the primes using roughly the same idea as RFC 3526, but rather than using pi as the "nothing up my sleeve" number, i've used zero (another well-known infinite sequence). If people see problems with this or think we should select the named groups in a different way, i'm happy to hear other proposals. regards, --dkg --e9VCccSRitrtswUCU3aupKQ1xH2EsRKGS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTNiLzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpch4MP/3CowYxy9DEQim1oiSlrEbNL wjeXup158DIa8a22MFklB0yaXOIfzCTyoVhxlXYvHzpEmE0V6dsAGH/IS1nCBDJL HTDMi3FNVhHz0qbcnYZHuz/Fmt8PYDTB/xKcFwFB4+il7RI85Tk+QpbQKVh8grHo FhaAxQX/A0Q1f4GMeIiVSvae0v7jBnx5AIvkgTfnA9osb8trAGrfm86/SeSmRA/5 5wUxVxus42XM5jJ+EnspzkUxrp/7fBzRsoaF3zKmn7tGUmQPHU7g1HuQli2AIPJW mU9W258jM3QfMX2+M0dxvxBFBZApbdTqTyDGtXHH17pKtmwdzC2bkxcaNNru72C1 +aptA7YDyT78sCmlfJzy/24D3SYON2zAu/c1NgInIRVNISId5Gqvj4NfawZ6r0LC jiXHOur3nhk17bZZQ9STOcv95b/0yPXsaZdMq2xCMi08QXC0UGGUDeNx6z+xGI9e RFH1ktTulLWTX72RBAqWOlQ1zSXosqdkD7JxC6dzYV/dn/x3UTV3TMc3w9SLUCrE LSF3Vz/Jdd7vkGy11bxiDDNQiqtD4JfAT6HCV1tl+sRov76ACHVBT5iktQ4M851R 9hLrg4WWKa80/ia8Fkwc4CfMqGEIWiLuxkjG3YKYDJg/HK2SYojrow1hcJMA6HVN rLWKFd0D9twFuidheIAI =5V02 -----END PGP SIGNATURE----- --e9VCccSRitrtswUCU3aupKQ1xH2EsRKGS-- From nobody Fri Mar 28 18:40:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4C21A025B for ; Fri, 28 Mar 2014 18:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78tRJ-z5iwEv for ; Fri, 28 Mar 2014 18:40:45 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) by ietfa.amsl.com (Postfix) with ESMTP id CA59E1A0755 for ; Fri, 28 Mar 2014 18:40:44 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 9so1432090ykp.10 for ; Fri, 28 Mar 2014 18:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SQUXWzszKN2rMpTyadeQxX6qTmX0Bo0Tla4HsxIscs0=; b=tsR9/qkT/laE6K6hk+joWo3B4aFWTaGS/tYhszbQ1ZQhuLWs4W1yu7zxgySzDpPKzc tX8QKsOpDxw9FotkI9RlR8HwpfvQEPNP12fuVL8aGcWRz5j/bjnrLK2Xg5OqfGGmG1TW bfRIvUTgRKQmH8HBUWzH0Zt9r4AG2ggNrT27d+JnJNeMYjzbEfL0vcPVHMiKH72cBj1m 7qpxBOT3cp3u2yF04tscnEJQVmUOgEO2QmkaJMURQBCfkWltZZVvM67wQqmKe+r9ITCb sMvZPB8BVMuSrjUsQvcDQbpcSAxtKn3+59Ci341ESinO/g6F5yMfLwZ+7MOATTcNTvtE ZydA== MIME-Version: 1.0 X-Received: by 10.236.147.10 with SMTP id s10mr15938544yhj.88.1396057242466; Fri, 28 Mar 2014 18:40:42 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Fri, 28 Mar 2014 18:40:42 -0700 (PDT) In-Reply-To: References: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> Date: Fri, 28 Mar 2014 21:40:42 -0400 Message-ID: From: Watson Ladd To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/11vIKakckR4QfCtVp0dWbaJMk8o Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-pwd-04.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: Sat, 29 Mar 2014 01:40:48 -0000 On Fri, Mar 28, 2014 at 8:07 PM, Dan Harkins wrote: > > On Fri, March 28, 2014 4:35 pm, Watson Ladd wrote: >> On Fri, Mar 28, 2014 at 6:55 PM, Dan Harkins wrote: >>> >>> On Fri, March 28, 2014 2:49 pm, Watson Ladd wrote: >>>> On Fri, Mar 28, 2014 at 3:53 PM, wrote: >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Transport Layer Security Working >>>>> Group >>>>> of the IETF. >>>>> >>>>> Title : Secure Password Ciphersuites for Transport >>>>> Layer Security (TLS) >>>>> Authors : Dan Harkins >>>>> Dave Halasz >>>>> Filename : draft-ietf-tls-pwd-04.txt >>>>> Pages : 35 >>>>> Date : 2014-03-28 >>>> >>>> Why should we trust this PAKE? I've got only partial results in this >>>> direction, but they are not sufficient for me to adopt it when better >>>> validated alternatives exist like those based on distrustful MPC. >>> >>> I'm not sure what you mean by "we" but it got quite a bit of review >>> in CFRG and that resulted in fixing the only real technical issue >>> brought >>> up: potential for a side-channel attack. Scott Fluhrer came up with a >>> way to do a random blinding of a value when checking whether its a >>> quadratic residue that effectively addresses that concern. >> >> "We didn't break it in the four months we've looked at it" is not a >> good enough reason. >> Given that the experts you have consulted have expressed doubts about >> ever determining its security, I'm inclined to be rather more >> suspicious of it. > > It's been more like 2 years, but nevertheless, your complaint is a > lack of formal security proof. But that has never been a requirement > for a draft in a WG in the Security Area, or any area for that matter, > of the IETF. So because I didn't complain when the Security Area was founded, I don't get to complain now? This takes estoppel to a bizarre extreme. > >> During the last half of those two months I was trying to show it would >> work. The best I can do is reduce it to the two person case, but I >> can't get it to anything computational. > > What a drag, I was hoping you'd come up with something. > >>> These ciphersuites are drop-in replacements for things like PSK >>> ciphersuites, not for popular ones used in browsers. In fact, I agree >>> with several on this list who are pointing out that using a PAKE in a >>> browser is not a good idea. >> >> Why is a multi-party computation ala Socialist Millionaire's protocol >> in OTR not feasible? That establishes a secure channel based on a >> password shared on both ends in a way that is provably secure. >> Aug-PAKE can easily be made to work symmetrically: why can't you use >> that? > > There is no draft specifying a multi-party computation ala the > Socialist Millionaire's protocol in TLS, much less one that is as > mature as TLS-pwd. Aug-PAKE doesn't work in TLS, as shown > by draft-shin-tls-augpake-- what's conveyed in the ClientKeyExchange > structure since the client's contribution has been overloaded into > the ClientHello? Basically, the client must initiate in Aug-PAKE and > that forces a square peg into a round hole, or introduces extra > rounds. Write one. It's your problem, not mine. As for AugPAKE, that might be ugly, but it works. I'm not seeing a barrier to implementation here. Furthermore, we could reverse the roles of client and server if we wanted a symmetric version in which the client talks first. > > We have gone over this before, but it takes years to get a draft > in the state necessary to become an RFC. You said it took more > like 30 minutes, but I'm sure you'd like to reevaluate that after > your experience with the CFRG I-D you have been writing. In > any event, the only draft _right now_ that satisfies the requirements > is TLS-pwd. The concerns I have with Dragonfly cannot be fixed by fiddling with verbiage. They are fundamental problems with the protocol presented compared to the state of the art. > >> There are standard models for PAKE security. Does Dragonfly work in >> them? It clearly requires the ROM: is that enough? >> >> You're asking this WG to approve adding a new cryptographic protocol >> to TLS with dubious justifications, in fact nonexistent, of security, >> when a well-studied body of knowledge on this problem exists. There is >> a compelling case for a PAKE: there is not a compelling case for >> Dragonfly. > > The same WG that approved of RFC 4279, a Standards Track RFC that > did not have a proof in the ROM because it has no security. Yes, that same > WG. I'm proposing a set of robust and misuse-resistant replacements for > the RFC 4279 ciphersuites. PSK has no security? That's ridiculous: if high-entropy keys are used it is fairly easy to see it is secure. Dragonfly's "robustness" and "misuse-resistence" are nothing but rhetoric, absent some reason to believe it actually has these properties. Sincerely, Watson Ladd > > regards, > > Dan. > >> Sincerely, >> Watson Ladd >>> >>> If you're happy doing cert-based TLS, or happy with HTTP Digest >>> authentication (or whatever) then these are not for you. But the >>> entirety >>> of networking is not "the web" and these ciphersuites work well with >>> some specific use cases (see the draft). >>> >>> regards, >>> >>> Dan. >>> >>> >> >> >> >> -- >> "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 nobody Fri Mar 28 23:32:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400CE1A077B for ; Fri, 28 Mar 2014 23:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxxXGX-ETPkp for ; Fri, 28 Mar 2014 23:32:14 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 983DE1A0775 for ; Fri, 28 Mar 2014 23:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1396074732; x=1427610732; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=co7TWM748D2UQCqRxCyMQ3e72ArFNqRHfspdgWF9jgA=; b=hMRRsti4tTatstizX/GqK5U4GP3+8+s38mIS0mN/kR/bpKTNdjhnvUGM Fsvk7uLtieXqzdJvB1vC7oYtoOJBrSCufBHbZn7gcrtRaKAZWXtw29gmY ioEnU2THKaShtXT0Mev1k4hd4Voam+zx/a36y+x/N+aStwrxboXOLZQut 4=; X-IronPort-AV: E=Sophos;i="4.97,755,1389697200"; d="scan'208";a="243517826" 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; 29 Mar 2014 19:32:08 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.03.0174.001; Sat, 29 Mar 2014 19:32:07 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] TLS 1.3 process Thread-Index: Ac9LGJtcwnMdIAC6QBS+Ty3Vj5y3QQ== Date: Sat, 29 Mar 2014 06:32:07 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7372395446@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xC7uhgezZ1Xnur-RvwWIg2gIhMY Subject: Re: [TLS] TLS 1.3 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: Sat, 29 Mar 2014 06:32:17 -0000 Stephen Farrell writes:=0A= =0A= >I'm sure others who were more involved will correct me, but wasn't the IKE= v1=0A= >fun in large part caused by not being able to pick a winner from not-hugel= y-=0A= >different competing proposals, with a sprinkling of not easily handled=0A= >personalities and other competing interests involved?=0A= =0A= >From Jeff Schiller's comment and recollections by others who were involved = it=0A= was more a problem of politics, the authors of Photuris were either difficu= lt=0A= to work with or unwilling to compromise their elegant design depending on= =0A= which side you're on so Photuris couldn't be used, SKIP was from Sun so tha= t=0A= couldn't be used, and the result was a design-by-committee mess.=0A= =0A= Also, the solution isn't necessarily a competition per se but the way that = the=0A= competition channels the design. What's needed is an elegant design create= d=0A= by a very small number of talented people, not the outcome of several years= of=0A= horse-trading put in an RFC. Look at all of the successful mainstream=0A= Internet security protocols: SSL, three people. S/MIME, two(?) people. PG= P,=0A= one person. SSH... well, it started out with a small number of people at=0A= SSH.com and then got hacked and kludged endlessly, but close enough.=0A= =0A= The competition format more or less requires the "small group of talented= =0A= individuals" design, you can't submit a design-by-committee entry to a=0A= competition because (a) a committee will never agree on a single design bef= ore=0A= the competition closes and (b) the committee design will be such a mess tha= t=0A= it'll never get picked.=0A= =0A= My preference (which I've expressed off-list) would be just to take SKEME,= =0A= come up with a single unambiguous profile for it (not the kitchen-sink IPse= c=0A= interpretation), and call that TLS 2.0. The crypto framework is already=0A= there, you just need to provide a wire format for it and nail down a single= =0A= interpretation that everyone speaks.=0A= =0A= Peter.= From nobody Fri Mar 28 23:38:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76951A077B for ; Fri, 28 Mar 2014 23:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nI_CoKWDz9yj for ; Fri, 28 Mar 2014 23:38:35 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 3307A1A0775 for ; Fri, 28 Mar 2014 23:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1396075113; x=1427611113; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=+tKTM9RbePuoyWVSN5oONvUeGNu2Pu9sevKdflTPF8A=; b=pGY1slk+8S8ftAYwCgXUyQoQuuxAYbyotGGOtcpIAK8wx4WzR9EX8L4R DcAuJ6W4gdGVgZJ/VCKihEaGShkT8XY2PNjKczjUxpcFU6/2CUtgy+4rQ b4p4L1cbQlAvtEY/MAWHFuE6LcNKBfyfcXXBbBbCRoLyShnI9bsO+4wW4 M=; X-IronPort-AV: E=Sophos;i="4.97,755,1389697200"; d="scan'208";a="243519366" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 29 Mar 2014 19:38:32 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Sat, 29 Mar 2014 19:38:32 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] TLS 1.3 process Thread-Index: Ac9LGYBR78ue6w+8Qwysb5eQ8bsAWA== Date: Sat, 29 Mar 2014 06:38:31 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7372395453@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EBLhlU5cHaMwlX03Kf-93_rEQbo Subject: Re: [TLS] TLS 1.3 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: Sat, 29 Mar 2014 06:38:36 -0000 Nikos Mavrogiannopoulos writes:=0A= =0A= >However, the majority of the TLS protocol was designed outside the IETF=0A= >processes, and the result I believe was more than satisfactory.=0A= =0A= As was S/MIME, PGP, and early drafts of SSH (and by "SSH" I mean SSHv2=0A= obviously). The IETF just took over a more or less complete design wholesa= le=0A= and went with it. Of the major Internet security protocols, the only one t= hat=0A= was done via the IETF process was, uh, IPsec.=0A= =0A= Peter.=0A= From nobody Fri Mar 28 23:49:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60941A077B for ; Fri, 28 Mar 2014 23:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIGDt9zs9dOL for ; Fri, 28 Mar 2014 23:49:30 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC081A0775 for ; Fri, 28 Mar 2014 23:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1396075768; x=1427611768; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=steEr/EL9vCY26HKjskgxfoCj5XFT0oBnaAu6s91uow=; b=fagaGS6yhIhxw+FH4aEOfo1SMA3vr3xIHQX+Vx84OiuvfEMJszQ0dmBS +jLmQRjBgL3acGPC4T7M35T8UZYjE2Bcq5b4X5QX3N0B+Y2o5aClwbcme 0xJ3EinTP+wpjz5+BRWwsOjxaTQ4CFmpyvn+LV6E5dtt5q8Hpkk8Kn/y1 w=; X-IronPort-AV: E=Sophos;i="4.97,755,1389697200"; d="scan'208";a="243520329" 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; 29 Mar 2014 19:49:27 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.03.0174.001; Sat, 29 Mar 2014 19:49:27 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] TLS 1.3 process Thread-Index: Ac9LGstTO2tDjcoISSCDrCseSVscCQ== Date: Sat, 29 Mar 2014 06:49:26 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7372395465@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dwpPajUShQfi92ncrv_Sw5IGmvo Subject: Re: [TLS] TLS 1.3 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: Sat, 29 Mar 2014 06:49:31 -0000 Adam Langley writes:=0A= =0A= >I would rather like to see a TLS 1.3 that is a tidying up of 1.2: merging = the=0A= >various RFCs into one, editing and pulling in some of the drafts that are= =0A= >floating around. The more significant changes could be 1.4.=0A= =0A= Absolutely! I don't want to have to add yet another parallel implementatio= n=0A= of a protocol that's just different enough that it's yet another set of cod= e=0A= and functionality to test, alongside SSLv3, TLS 1.0, and TLS 1.2. All of t= he=0A= previous updates have been compatible enough that you don't want to do a ne= w=0A= implementation, but incompatible enough that it's a different protocol. Ma= ke=0A= 1.3 purely fixes for 1.2 and then start again with 2.0 so we can ditch all = the=0A= old baggage, complexity, and attack surface.=0A= =0A= Peter.=0A= From nobody Fri Mar 28 23:53:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978FC1A077C for ; Fri, 28 Mar 2014 23:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erMcWih0O-Kk for ; Fri, 28 Mar 2014 23:53:03 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE801A0775 for ; Fri, 28 Mar 2014 23:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1396075981; x=1427611981; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=3i9qkkTMfB6eVySI/V1jD/hd2jO1aN0zyS1ujsayhHk=; b=G2eFVeOUd/b2QPatwCPEfoU33K1IDPAkl+L9poo4EaqonKIR+qAX3uSe lRpeK/OzhPlyS93RvgeL1xJg528c4qIGQNrL6tcYaNmLq58uf5LNrr8LY tHL/+9/EOA36zovFoCYjptZw2nKKRAu+zELqJjM54GDPCuxId14hS2Ybf s=; X-IronPort-AV: E=Sophos;i="4.97,755,1389697200"; d="scan'208";a="243520785" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 29 Mar 2014 19:53:00 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Sat, 29 Mar 2014 19:53:00 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) Thread-Index: Ac9LG4Wc+JJ79Rl6RbOxzXbcnLv0dw== Date: Sat, 29 Mar 2014 06:52:59 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C737239546F@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qQD0dFGTIxcmZlEcQdW9eX2kTIA Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 06:53:04 -0000 Andrei Popov writes:=0A= =0A= >"Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update spring 201= 4"=0A= >adds a couple of DHE_RSA cipher suites: TLS_DHE_RSA_WITH_AES_256_GCM_SHA38= 4=0A= >TLS_DHE_RSA_WITH_AES_128_GCM_SHA256=0A= =0A= Those are all 1.2 suites with its barely-there deployment, what about addin= g=0A= pre-1.2 suites as well for the 99.whatever% market penetration the earlier= =0A= versions have?=0A= =0A= Peter.= From nobody Sat Mar 29 15:49:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BA81A07FC for ; Sat, 29 Mar 2014 15:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO3vKZ2T7T3m for ; Sat, 29 Mar 2014 15:49:53 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id C60881A07FE for ; Sat, 29 Mar 2014 15:49:53 -0700 (PDT) Received: from [174.240.36.91] (helo=Williams-MacBook-Pro.local) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WU24U-0007zz-Qu for tls@ietf.org; Sat, 29 Mar 2014 17:49:51 -0500 Date: Sat, 29 Mar 2014 15:49:14 -0700 From: Bill Frantz To: tls@ietf.org X-Priority: 3 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79271b8b468810e1e1397cd67cd370394b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.240.36.91 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/R8G-GIHIh1JyVE_G7i1jAhtBGy4 Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Mar 2014 22:49:55 -0000 It causes security problems. It adds code to a security module (i.e. TLS). It can easily and securely be added externally (by separately=20 compressing items from different security contexts). I say nuke it. 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 nobody Sat Mar 29 15:50:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6621A081B for ; Sat, 29 Mar 2014 15:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SMFAQXx1TA1n for ; Sat, 29 Mar 2014 15:49:56 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 67E081A080A for ; Sat, 29 Mar 2014 15:49:56 -0700 (PDT) Received: from [174.240.36.91] (helo=Williams-MacBook-Pro.local) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WU24X-0007zz-5V for tls@ietf.org; Sat, 29 Mar 2014 17:49:53 -0500 Date: Sat, 29 Mar 2014 15:49:16 -0700 From: Bill Frantz To: tls@ietf.org X-Priority: 3 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE833@USMBX1.msg.corp.akamai.com> 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79271b8b468810e1e10ec309bd5f5b8798350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.240.36.91 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wZvs9psjYHOMYyBs_5_DRcM-Jqs Subject: Re: [TLS] TLS 1.3 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: Sat, 29 Mar 2014 22:49:58 -0000 One place where IMHO, the process is lacking is in having a set=20 use cases to test our proposals against. With use cases, we can=20 more easily avoid the tendency to Baroque and Rococo interfaces=20 by asking how a particular feature supports one of our use=20 cases. The proposer can either answer how it supports an=20 existing use case, or propose a new use case which does support.=20 Than new use case can be either added or rejected by the group. It seems to me obvious that two use cases we must support for=20 TLS are: HTTP Mail (POP, SMTP, IMAP) Are there any others? I don't know much about the real-world uses of DTLS, so others=20 will have to propose DTLS use cases. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz | Re: Computer reliability, performance, and security: 408-356-8506 | The guy who *is* wearing a parachute is=20 *not* the www.pwpconsult.com | first to reach the ground. - Terence Kelly From nobody Sat Mar 29 16:11:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3101A07FE for ; Sat, 29 Mar 2014 16:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_EzWfDhkUes for ; Sat, 29 Mar 2014 16:11:15 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 52DCB1A06B9 for ; Sat, 29 Mar 2014 16:11:15 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so444803wib.11 for ; Sat, 29 Mar 2014 16:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Jp6927wijE0jlXdPNDsmGNnqvUgc2j4fHLJrFFCX9XU=; b=oRXCEwzHiTyf2M/dfGGVMMMb/5Lxp0ZKgTABJIGL8Iwgs3G0BHnOT16JVROarmro8k klp/H/GQfSbVMZTDZItwlDF6seZNSnxtrnTo3sRro3VRC3jE2HCNn/emzR7dVcYtedrs ZeuK4Coa+ww0aRp8EBgaC+XzoJygSkkysgknI01BIBZ8uTMNaMo7/DkzXZsDMe80k1Ix YNxwTWqqR8JcdWwfUyNk93bvURduBwv0wq/UqkgfxjGhqArcF9VMFjw14teJ8hGdWEhV ie66vvm1lAa41qkpMn4xKCnImgvcK827uPxUKUnkgWSFLlScTu7SLgIeiF9jF4IRE58H jq1g== MIME-Version: 1.0 X-Received: by 10.194.203.170 with SMTP id kr10mr5010357wjc.19.1396134672096; Sat, 29 Mar 2014 16:11:12 -0700 (PDT) Received: by 10.194.243.101 with HTTP; Sat, 29 Mar 2014 16:11:12 -0700 (PDT) Received: by 10.194.243.101 with HTTP; Sat, 29 Mar 2014 16:11:12 -0700 (PDT) In-Reply-To: References: Date: Sun, 30 Mar 2014 00:11:12 +0100 Message-ID: From: Richard Hartmann To: "Joseph Salowey (jsalowey)" Content-Type: multipart/alternative; boundary=047d7b6d87de30636004f5c6efa7 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fYLa4LzzdE4dEUO0NQYaUP1SJmU Cc: "" Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Mar 2014 23:11:18 -0000 --047d7b6d87de30636004f5c6efa7 Content-Type: text/plain; charset=UTF-8 +1 for removal. Richard Sent by mobile; excuse my brevity. --047d7b6d87de30636004f5c6efa7 Content-Type: text/html; charset=UTF-8

+1 for removal.

Richard

Sent by mobile; excuse my brevity.

--047d7b6d87de30636004f5c6efa7-- From nobody Sat Mar 29 18:57:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C0D1A0416 for ; Sat, 29 Mar 2014 18:57:32 -0700 (PDT) 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 ZOpiB-MPDuS4 for ; Sat, 29 Mar 2014 18:57:31 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 44E621A040E for ; Sat, 29 Mar 2014 18:57:31 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3F821A888012; Sat, 29 Mar 2014 18:57:28 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 29 Mar 2014 18:57:28 -0700 (PDT) Message-ID: <5e873b6dee53a2ba2cbce891c1dc43dc.squirrel@www.trepanning.net> In-Reply-To: References: Date: Sat, 29 Mar 2014 18:57:28 -0700 (PDT) From: "Dan Harkins" To: "Bill Frantz" 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ufHCfftjfr2JW7viukt5Epjt-uM Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 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, 30 Mar 2014 01:57:32 -0000 Hi Bill, On Sat, March 29, 2014 3:49 pm, Bill Frantz wrote: > One place where IMHO, the process is lacking is in having a set > use cases to test our proposals against. With use cases, we can > more easily avoid the tendency to Baroque and Rococo interfaces > by asking how a particular feature supports one of our use > cases. The proposer can either answer how it supports an > existing use case, or propose a new use case which does support. > Than new use case can be either added or rejected by the group. > > It seems to me obvious that two use cases we must support for > TLS are: > > HTTP > > Mail (POP, SMTP, IMAP) > > Are there any others? See /etc/services. Basically, everything that uses the transport layer should be able to use transport layer security if it wants to. I think we should avoid to the fullest extent possible having application layer use cases to guide TLS 1.3 development. The less the application layer intrudes onto TLS the better. (I think NPN/ALPN is architecturally a bad idea). regards, Dan. > I don't know much about the real-world uses of DTLS, so others > will have to propose DTLS use cases. > > Cheers - Bill > > --------------------------------------------------------------------------- > Bill Frantz | Re: Computer reliability, performance, and security: > 408-356-8506 | The guy who *is* wearing a parachute is > *not* the > www.pwpconsult.com | first to reach the ground. - Terence Kelly > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sat Mar 29 20:06:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8201A0745 for ; Sat, 29 Mar 2014 20:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K060X0hMtja for ; Sat, 29 Mar 2014 20:06:12 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5421A073F for ; Sat, 29 Mar 2014 20:06:11 -0700 (PDT) Received: from [174.253.224.172] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WU64V-0003il-8k; Sat, 29 Mar 2014 23:06:08 -0400 Date: Sat, 29 Mar 2014 20:05:28 -0700 From: Bill Frantz To: Dan Harkins X-Priority: 3 In-Reply-To: <5e873b6dee53a2ba2cbce891c1dc43dc.squirrel@www.trepanning.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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79da52669b1f90549cf5da48bf770e2f42350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.253.224.172 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HuaKXLbtErS4UP8n-FS2KWzQPOM Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 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, 30 Mar 2014 03:06:13 -0000 On 3/29/14 at 6:57 PM, dharkins@lounge.org (Dan Harkins) wrote: >See /etc/services. Basically, everything that uses the transport layer >should be able to use transport layer security if it wants to. Transport layer doesn't have key agreement, end point=20 authentication, reconnect etc. etc. etc. We need use cases to=20 define what is needed in these areas. Watson is correctly concerned that we get the transport=20 encryption to work correctly. Transport layer encryption might=20 include bi-directional data transport, end point synchronization=20 etc., but if there are no use cases, it is hard to justify=20 spending a lot of effort to support them. We need use cases if only to be sure we are supporting what=20 needs to be supported. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Since the IBM Selectric, keyboards have gotten 408-356-8506 | steadily worse. Now we have touchscreen keyboards. www.pwpconsult.com | Can we make something even worse? From nobody Sun Mar 30 09:23:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF09A1A0895 for ; Sun, 30 Mar 2014 09:23:19 -0700 (PDT) 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 9B-Iayf25Q3k for ; Sun, 30 Mar 2014 09:23:18 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 31EFE1A065C for ; Sun, 30 Mar 2014 09:23:18 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D5764A888012; Sun, 30 Mar 2014 09:23:14 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 30 Mar 2014 09:23:15 -0700 (PDT) Message-ID: <8812ef304b84ab08775b790b9a2ac415.squirrel@www.trepanning.net> In-Reply-To: References: Date: Sun, 30 Mar 2014 09:23:15 -0700 (PDT) From: "Dan Harkins" To: "Bill Frantz" 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1fKtglmRTw6reTphVnbwcRtUT08 Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 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, 30 Mar 2014 16:23:20 -0000 On Sat, March 29, 2014 8:05 pm, Bill Frantz wrote: > On 3/29/14 at 6:57 PM, dharkins@lounge.org (Dan Harkins) wrote: > >>See /etc/services. Basically, everything that uses the transport layer >>should be able to use transport layer security if it wants to. > > Transport layer doesn't have key agreement, end point > authentication, reconnect etc. etc. etc. That's what Transport Layer _Security_ (i.e. TLS) is for. > We need use cases to > define what is needed in these areas. I disagree. > Watson is correctly concerned that we get the transport > encryption to work correctly. Transport layer encryption might > include bi-directional data transport, end point synchronization > etc., but if there are no use cases, it is hard to justify > spending a lot of effort to support them. Well bully for Watson. But everyone in the WG is concerned about getting encryption to work correctly. We're also all concerned about getting authentication to work correctly. And about getting authenticated encryption to work correctly. I fail to see how documenting use cases will help us get encryption to work correctly, unless you think there are some use cases for which correctly working encryption is not a requirement. If that's the case then then have no impact on TLS 1.3. > We need use cases if only to be sure we are supporting what > needs to be supported. Documenting use cases is an unnecessary distraction from doing actual work. You'll note that our charter does not say "enumerate applications that want to use TLS". Dan. > Cheers - Bill > > ----------------------------------------------------------------------- > Bill Frantz | Since the IBM Selectric, keyboards have gotten > 408-356-8506 | steadily worse. Now we have touchscreen keyboards. > www.pwpconsult.com | Can we make something even worse? > > From nobody Sun Mar 30 09:56:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222201A089B for ; Sun, 30 Mar 2014 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QqvvIb6o0e2 for ; Sun, 30 Mar 2014 09:56:39 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4A26F1A06EA for ; Sun, 30 Mar 2014 09:56:39 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2F495165590; Sun, 30 Mar 2014 16:56:36 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (unknown [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 241EC165588; Sun, 30 Mar 2014 16:56:36 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id F2ED59803D; Sun, 30 Mar 2014 16:56:35 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Sun, 30 Mar 2014 12:56:35 -0400 From: "Salz, Rich" To: Dan Harkins , Bill Frantz Date: Sun, 30 Mar 2014 12:56:34 -0400 Thread-Topic: [TLS] TLS 1.3 process Thread-Index: Ac9MNHDXJVsFytQcSwSa3cBsJuAKxwAA8/0w Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FD90EE3E@USMBX1.msg.corp.akamai.com> References: <8812ef304b84ab08775b790b9a2ac415.squirrel@www.trepanning.net> In-Reply-To: <8812ef304b84ab08775b790b9a2ac415.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9BBZncyjSI1QMLCPEhLCk07ao3I Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 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, 30 Mar 2014 16:56:40 -0000 One use (sic) of use-cases is that they are helpful to determine what's in-= scope and what's out of scope. For example, DNS is typically over UDP and = doesn't care about replay or out of order. TLS-layer compression has securi= ty issues, and arguably application-level compression can be more effective= by leveraging semantics (e.g., HTTP2 headers). Both of those cases impact= encryption. I share the concern about not being distracted, but nowhere near as strongl= y as Dan. And we're certainly not all concerned about getting authenticati= on working correctly; it depends on what the definition of correctly is, I = suppose. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Sun Mar 30 16:47:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624F11A08EA for ; Sun, 30 Mar 2014 16:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAM8Dx0u0woj for ; Sun, 30 Mar 2014 16:47:04 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE1F1A08E4 for ; Sun, 30 Mar 2014 16:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1396223221; x=1427759221; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=1Xxig9F7m9VuJhGz/XmOkjMYIinTxtv8RBXtNOCGElU=; b=R5vuDi0SEz58SSSnDM7O/U+ceaB3ITWv9tEoBlliTeZV98kclQvVSOhE HK4UKCxpQtwGd897Spv9cJiz+2pYggiXhF3zCYl1icjx1+DdCoTQShBH2 71/WcvCnsMcU63BxgWQ6B3sO6xRC85tMzHbTKDF2KiRw7HaMbgZyw90Na k=; X-IronPort-AV: E=Sophos;i="4.97,761,1389697200"; d="scan'208";a="243835725" 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 Mar 2014 12:46:58 +1300 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.111]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Mon, 31 Mar 2014 12:46:57 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] TLS 1.3 process Thread-Index: Ac9MclYHHCcYDGdIRdywo9NEYSgKMQ== Date: Sun, 30 Mar 2014 23:46:57 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738A33738A@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V_iOoArEMc1aav0AQY0lIl6hLbw Subject: Re: [TLS] TLS 1.3 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, 30 Mar 2014 23:47:06 -0000 Dan Harkins writes:=0A= =0A= >But everyone in the WG is concerned about getting encryption to work=0A= >correctly. We're also all concerned about getting authentication to work= =0A= >correctly. And about getting authenticated encryption to work correctly.= =0A= =0A= Some of us are more worried about making it fit for purpose than in fiddlin= g=0A= with crypto details. The former requires careful thought, for the latter y= ou=0A= just pull a known-good mechanism off the shelf at the end of the design=0A= process, plug it in, and you're done. To quote Peter Fairbrother on the=0A= crypto list:=0A= =0A= A similar design methodology should be used for security products (and=0A= software products). Start with the purpose of the product, then the huma= n=0A= and electronic interfaces, then the hardware and last of all the detailed= =0A= crypto or code. Oh yes, you think about the crypto all the way through, b= ut=0A= only in terms of what is possible and what resources it will take - worry= =0A= about the detailed crypto (or code) last.=0A= =0A= >I fail to see how documenting use cases will help us get encryption to wor= k=0A= >correctly=0A= =0A= It'll allow us to see whether the encryption is fit for purpose. Since I'm= in=0A= a quoting mood I'll do Bob Morris this time:=0A= =0A= The behaviour of a system without a specification can never be wrong, onl= y=0A= surprising.=0A= =0A= TLS has certainly shown some... surprising behaviour over its lifetime.=0A= =0A= Peter.= From nobody Sun Mar 30 17:34:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5E41A08FE for ; Sun, 30 Mar 2014 17:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XIKVsBJFeRYK for ; Sun, 30 Mar 2014 17:34:07 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id AF0BC1A08F9 for ; Sun, 30 Mar 2014 17:34:07 -0700 (PDT) Received: from [174.239.227.84] (helo=Williams-MacBook-Pro.local) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WUQAt-0001jH-76; Sun, 30 Mar 2014 19:34:03 -0500 Date: Sun, 30 Mar 2014 17:33:28 -0700 From: Bill Frantz To: Dan Harkins X-Priority: 3 In-Reply-To: <8812ef304b84ab08775b790b9a2ac415.squirrel@www.trepanning.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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79c4c62d7bd057c04cfa5a4cce3f76c442350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.239.227.84 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/o4kcKhPS21na5mkKoRtXwgq-aZA Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 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: Mon, 31 Mar 2014 00:34:10 -0000 On 3/30/14 at 9:23 AM, dharkins@lounge.org (Dan Harkins) wrote: >>Watson is correctly concerned that we get the transport >>encryption to work correctly. Transport layer encryption might >>include bi-directional data transport, end point synchronization >>etc., but if there are no use cases, it is hard to justify >>spending a lot of effort to support them. > >... everyone in the WG is concerned >about getting encryption to work correctly. We're also all >concerned about getting authentication to work correctly. >And about getting authenticated encryption to work correctly. > >I fail to see how documenting use cases will help us get >encryption to work correctly, unless you think there are some >use cases for which correctly working encryption is not a >requirement. If that's the case then then have no impact on >TLS 1.3. SSL/TLS was built with one use case in mind -- HTTP. As a=20 result, TLS authentication is optimized for the stranger meets=20 stranger case where a user wants a secure connection to a web=20 site knowing only the domain name. This HTTP oriented=20 authentication is poorly adapted to the requirements of=20 encrypted communication with email servers where connections=20 between the email user and the server are repeated many times a=20 day, day after day. What other application areas are also poorly=20 served? Without use cases we have no idea. The problem isn't that we all don't want encryption,=20 authentication, traffic analysis resistance etc. to work=20 correctly. The problem is that we don't know what correct=20 operation is. And we can't know unless we have an idea of what=20 at least some of the uses are. >>We need use cases if only to be sure we are supporting what >>needs to be supported. > >Documenting use cases is an unnecessary distraction from >doing actual work. You'll note that our charter does not say >"enumerate applications that want to use TLS". We don't have to enumerate all the uses. What we have to do is=20 have enough examples of different uses to let us have a chance=20 that we are actually serving a wide range of them. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | "The only thing we have to | Periwinkle (408)356-8506 | fear is fear itself." - FDR | 16345=20 Englewood Ave www.pwpconsult.com | Inaugural address, 3/4/1933 | Los Gatos,=20 CA 95032 From nobody Sun Mar 30 18:16:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0FC1A0906 for ; Sun, 30 Mar 2014 18:16:24 -0700 (PDT) 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 zkB0zgw0himP for ; Sun, 30 Mar 2014 18:16:22 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2F71A08FC for ; Sun, 30 Mar 2014 18:16:22 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2FC8FA888012; Sun, 30 Mar 2014 18:16:19 -0700 (PDT) Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 30 Mar 2014 18:16:19 -0700 (PDT) Message-ID: <4902faea2d2548bb796379ea22330437.squirrel@www.trepanning.net> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738A33738A@uxcn10-tdc06.UoA.auckland.ac .nz> References: <9A043F3CF02CD34C8E74AC1594475C738A33738A@uxcn10-tdc06.UoA.auckland.ac.nz> Date: Sun, 30 Mar 2014 18:16:19 -0700 (PDT) From: "Dan Harkins" To: "Peter Gutmann" 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/T6hoNJtMlAG-Go9iHRTxFe2Z27Q Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 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: Mon, 31 Mar 2014 01:16:25 -0000 On Sun, March 30, 2014 4:46 pm, Peter Gutmann wrote: > Dan Harkins writes: > >>But everyone in the WG is concerned about getting encryption to work >>correctly. We're also all concerned about getting authentication to work >>correctly. And about getting authenticated encryption to work correctly. > > Some of us are more worried about making it fit for purpose than in > fiddling > with crypto details. Well if you do not care about encryption working correctly (it's a direct quote from the email I was replying to) then don't even bother with it; your purpose doesn't need encryption. And bringing up a use case that is happy with incorrect encryption is a waste of time for this WG. > The former requires careful thought, for the latter you > just pull a known-good mechanism off the shelf at the end of the design > process, plug it in, and you're done. To quote Peter Fairbrother on the > crypto list: > > A similar design methodology should be used for security products (and > software products). Start with the purpose of the product, then the > human > and electronic interfaces, then the hardware and last of all the > detailed > crypto or code. Oh yes, you think about the crypto all the way through, > but > only in terms of what is possible and what resources it will take - > worry > about the detailed crypto (or code) last. I agree. The purpose of TLS is to secure a network service (as I said originally, see /etc/services to see who'll use TLS). If we start listing that IMAP and POP and HTTP will use TLS-- "what else?"-- it's a distraction. >>I fail to see how documenting use cases will help us get encryption to >> work >>correctly > > It'll allow us to see whether the encryption is fit for purpose. Since > I'm in > a quoting mood I'll do Bob Morris this time: > > The behaviour of a system without a specification can never be wrong, > only surprising. You should try to find quotes that relate to what you're responding to. I never said anything about not having a specification and I never said we need to immediately start "fiddling with crypto details". I said that enumerating applications that use TLS is not a productive use of time (I certainly hope you are not equating a use case document with a specification), and I said that we are all concerned with making encryption work correctly (in response to the arresting statement that "Watson is concerned" about it). > TLS has certainly shown some... surprising behaviour over its lifetime. How would an enumerated list of the applications that use TLS, or a use case document for that matter, have helped any of that? Dan. > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sun Mar 30 21:09:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A431A094C for ; Sun, 30 Mar 2014 21:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvKPtZtmg13Z for ; Sun, 30 Mar 2014 21:09:10 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 81B831A08F9 for ; Sun, 30 Mar 2014 21:09:08 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id v1so7147401yhn.12 for ; Sun, 30 Mar 2014 21:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PYuRTfP6hlGo9BL4NdeHMKtgQKYiVuNVpaRQ4g9IHvU=; b=A7kKzM3xm5+270iEz7QVzDeg1C30WdqLljw3QqOuWogk8Ky/APCXku8Zl6yJC79tIt 8BaAUiOfom/E4iL6a20PJmCXowsS2xqUM9SoorN26Dja4GAnzGfI6SBi+65bzfpndxFM 3P/UdrY+sTu2rzlCcZHdj2qpKkYVzNfqfzcOxPP5OTs98RMMIRCWNHIZh+cRdNU3iV1D rPFqzhZWhW10Un568PQ2eJ84BzhT59lE1iP+DyXJgNxIP3odQF5iv5VaeSLh2Fo+avdC 6GMvn69UNpe1B57MfIOl3fFeuRX7HbFXZAmoBBtsNYuIlOPHpa1IA/BP2dBh7isFh4lI 9eGQ== MIME-Version: 1.0 X-Received: by 10.236.141.242 with SMTP id g78mr33443565yhj.50.1396238945427; Sun, 30 Mar 2014 21:09:05 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sun, 30 Mar 2014 21:09:05 -0700 (PDT) In-Reply-To: <4902faea2d2548bb796379ea22330437.squirrel@www.trepanning.net> References: <9A043F3CF02CD34C8E74AC1594475C738A33738A@uxcn10-tdc06.UoA.auckland.ac.nz> <4902faea2d2548bb796379ea22330437.squirrel@www.trepanning.net> Date: Sun, 30 Mar 2014 21:09:05 -0700 Message-ID: From: Watson Ladd To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LPdgs7szBghl0v74QgJlSUPXzqw Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 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: Mon, 31 Mar 2014 04:09:14 -0000 On Sun, Mar 30, 2014 at 6:16 PM, Dan Harkins wrote: > > On Sun, March 30, 2014 4:46 pm, Peter Gutmann wrote: >> Dan Harkins writes: >> >>>But everyone in the WG is concerned about getting encryption to work >>>correctly. We're also all concerned about getting authentication to work >>>correctly. And about getting authenticated encryption to work correctly. >> >> Some of us are more worried about making it fit for purpose than in >> fiddling >> with crypto details. > > Well if you do not care about encryption working correctly (it's a direct > quote from the email I was replying to) then don't even bother with it; > your purpose doesn't need encryption. And bringing up a use case that > is happy with incorrect encryption is a waste of time for this WG. But what do you mean by correct? INT-PTXT and IND-CCA2 would be my guess. But TLS of any version doesn't provide that; you have to implement the AES-GCM extension to get that. This still isn't fixed: you have to know the magic workarounds to make the existing, mandatory to implement protocol secure. Furthermore, how do you negotiate the key? Some applications rely on TLS negotiated keys being unique (channel binding for user authentication, GSAPI). This property doesn't hold for any of the basic negotiations discussed: you have to implement and use the ECDHE extension for that. So far from being a waste of time, the only applications the product of the WG is good for are those where encryption doesn't matter. I'm not even going to touch on the embarrassment of having a working group, UTA, created to clean up after us. > >> The former requires careful thought, for the latter you >> just pull a known-good mechanism off the shelf at the end of the design >> process, plug it in, and you're done. To quote Peter Fairbrother on the >> crypto list: >> >> A similar design methodology should be used for security products (and >> software products). Start with the purpose of the product, then the >> human >> and electronic interfaces, then the hardware and last of all the >> detailed >> crypto or code. Oh yes, you think about the crypto all the way through, >> but >> only in terms of what is possible and what resources it will take - >> worry >> about the detailed crypto (or code) last. > > I agree. The purpose of TLS is to secure a network service (as I said > originally, see /etc/services to see who'll use TLS). If we start listing > that > IMAP and POP and HTTP will use TLS-- "what else?"-- it's a distraction. Well, what do you mean by secure? TLS only tells you that you are talking to the possessor of a private key of some X509 certificate, and potentially shows some certificate chain leading there. For client authentication it falls flat: client certificates have ~1 organization using them, and that organization can make anything work by throwing enough billions at it. See the F-35 for details. At best TLS can be a useful tool, letting other people focus on how to turn X509 into what they really need ala DANE. However, they still need to deal with client authentication, and authorization is completely foreign to the entire bundle of technologies I've discussed here. > >>>I fail to see how documenting use cases will help us get encryption to >>> work >>>correctly >> >> It'll allow us to see whether the encryption is fit for purpose. Since >> I'm in >> a quoting mood I'll do Bob Morris this time: >> >> The behaviour of a system without a specification can never be wrong, >> only surprising. > > You should try to find quotes that relate to what you're responding to. > I never said anything about not having a specification and I never said > we need to immediately start "fiddling with crypto details". I said that > enumerating applications that use TLS is not a productive use of time > (I certainly hope you are not equating a use case document with a > specification), and I said that we are all concerned with making encryption > work correctly (in response to the arresting statement that "Watson is > concerned" about it). Everything about TLS is crypto details. What really matters is what TLS is supposed to do. This is not spelled out anywhere, let alone verified for TLS to work. It's the reason Martin Rex can argue BEAST wasn't a bug: with no spec to go against, it didn't violate anything but some sort of implicit understanding about what TLS was supposed to do. > >> TLS has certainly shown some... surprising behaviour over its lifetime. > > How would an enumerated list of the applications that use TLS, or a > use case document for that matter, have helped any of that? Well, it might have made EKR think twice before writing "This timing difference is believe to be too small to exploit" in an RFC. Formal methods could have trivially caught the renegotiation bug. If you look you will see renegotiation isn't actually defined anywhere: it's just casually mentioned that the example handshakes in the document aren't all the possibilities because you can restart them at any time. Channel bindings evolved later, and so no one looked to see if they were secure. Sincerely, Watson Ladd > > Dan. > >> Peter. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Mar 30 23:04:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D9A1A0966 for ; Sun, 30 Mar 2014 23:04:11 -0700 (PDT) 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 Og0YuOXzC8o5 for ; Sun, 30 Mar 2014 23:04:09 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 68A311A0963 for ; Sun, 30 Mar 2014 23:04:09 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 461B7A888012; Sun, 30 Mar 2014 23:04:06 -0700 (PDT) Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 30 Mar 2014 23:04:06 -0700 (PDT) Message-ID: In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C738A33738A@uxcn10-tdc06.UoA.auckland.ac.nz> <4902faea2d2548bb796379ea22330437.squirrel@www.trepanning.net> Date: Sun, 30 Mar 2014 23:04:06 -0700 (PDT) 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aC9uXyw1X9x420cFtmyhKQJfvmo Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 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: Mon, 31 Mar 2014 06:04:12 -0000 On Sun, March 30, 2014 9:09 pm, Watson Ladd wrote: > On Sun, Mar 30, 2014 at 6:16 PM, Dan Harkins wrote: >> >> On Sun, March 30, 2014 4:46 pm, Peter Gutmann wrote: >>> Dan Harkins writes: >>> >>>>But everyone in the WG is concerned about getting encryption to work >>>>correctly. We're also all concerned about getting authentication to >>>> work >>>>correctly. And about getting authenticated encryption to work >>>> correctly. >>> >>> Some of us are more worried about making it fit for purpose than in >>> fiddling >>> with crypto details. >> >> Well if you do not care about encryption working correctly (it's a >> direct >> quote from the email I was replying to) then don't even bother with it; >> your purpose doesn't need encryption. And bringing up a use case that >> is happy with incorrect encryption is a waste of time for this WG. > > But what do you mean by correct? INT-PTXT and IND-CCA2 would be my > guess. But TLS of any version doesn't provide that; you have to > implement the AES-GCM extension to get that. This still isn't fixed: > you have to know the magic workarounds to make the existing, mandatory > to implement protocol secure. Yes, IND-CCA is a good definition of encryption "working correctly". > Furthermore, how do you negotiate the key? Some applications rely on > TLS negotiated keys being unique (channel binding for user > authentication, GSAPI). This property doesn't hold for any of the > basic negotiations discussed: you have to implement and use the ECDHE > extension for that. Well, unless you can induce a server into reusing a random number across sessions even a cipher suite using RSA key exchange will produce a unique master key. And yes, ECDHE is an option. No need to enumerate protocols from /etc/services to arrive at that. > So far from being a waste of time, the only applications the product > of the WG is good for are those where encryption doesn't matter. I'm > not even going to touch on the embarrassment of having a working > group, UTA, created to clean up after us. It's easy to bitch about what other people did in the past (while oddly continuing to use the first person plural). But the discussion is whether the WG should enumerate use cases to decide whether TLS does what it needs to do. So far you have not made a compelling case. >>> The former requires careful thought, for the latter you >>> just pull a known-good mechanism off the shelf at the end of the design >>> process, plug it in, and you're done. To quote Peter Fairbrother on >>> the >>> crypto list: >>> >>> A similar design methodology should be used for security products >>> (and >>> software products). Start with the purpose of the product, then the >>> human >>> and electronic interfaces, then the hardware and last of all the >>> detailed >>> crypto or code. Oh yes, you think about the crypto all the way >>> through, >>> but >>> only in terms of what is possible and what resources it will take - >>> worry >>> about the detailed crypto (or code) last. >> >> I agree. The purpose of TLS is to secure a network service (as I said >> originally, see /etc/services to see who'll use TLS). If we start >> listing >> that >> IMAP and POP and HTTP will use TLS-- "what else?"-- it's a distraction. > > Well, what do you mean by secure? TLS only tells you that you are > talking to the possessor of a private key of some X509 certificate, > and potentially shows some certificate chain leading there. For client > authentication it falls flat: client certificates have ~1 organization > using them, and that organization can make anything work by throwing > enough billions at it. See the F-35 for details. Excellent, we have an existence proof for client authentication. And no justification for spending time enumerating use cases that require it. > At best TLS can be a useful tool, letting other people focus on how to > turn X509 into what they really need ala DANE. However, they still > need to deal with client authentication, and authorization is > completely foreign to the entire bundle of technologies I've discussed > here. Ah-ha! Finally something that is not bluster. Authorization is an interesting issue. I actually might change my mind on this whole use case thing if you can express a cogent case for what it should provide and for whom and why. On the other hand, if there's some application that requires some granular form of authorization it would behoove the stakeholders to express that need. A use case document isn't really necessary for that, but on the other hand it might help. >>>>I fail to see how documenting use cases will help us get encryption to >>>> work >>>>correctly >>> >>> It'll allow us to see whether the encryption is fit for purpose. Since >>> I'm in >>> a quoting mood I'll do Bob Morris this time: >>> >>> The behaviour of a system without a specification can never be wrong, >>> only surprising. >> >> You should try to find quotes that relate to what you're responding >> to. >> I never said anything about not having a specification and I never said >> we need to immediately start "fiddling with crypto details". I said that >> enumerating applications that use TLS is not a productive use of time >> (I certainly hope you are not equating a use case document with a >> specification), and I said that we are all concerned with making >> encryption >> work correctly (in response to the arresting statement that "Watson is >> concerned" about it). > > Everything about TLS is crypto details. What really matters is what > TLS is supposed to do. This is not spelled out anywhere, let alone > verified for TLS to work. It's the reason Martin Rex can argue BEAST > wasn't a bug: with no spec to go against, it didn't violate anything > but some sort of implicit understanding about what TLS was supposed to > do. You are obviously mistaking a use case document for a specification. >>> TLS has certainly shown some... surprising behaviour over its lifetime. >> >> How would an enumerated list of the applications that use TLS, or a >> use case document for that matter, have helped any of that? > > Well, it might have made EKR think twice before writing "This timing > difference is believe to be too small to exploit" in an RFC. Formal > methods could have trivially caught the renegotiation bug. If you look > you will see renegotiation isn't actually defined anywhere: it's just > casually mentioned that the example handshakes in the document aren't > all the possibilities because you can restart them at any time. > Channel bindings evolved later, and so no one looked to see if they > were secure. A use case document is not "formal methods", it's just a summary of use cases. And a use case document doesn't really translate into better definition of features. For all the shortcomings of TLS < 1.3 you haven't really explained how any of them were caused by the lack of a use case document or how a use case document for TLS 1.3 would ensure that they are not repeated. It is my experience that "problem statements" and "use case" documents are waste of at least 12 months and sometimes 18 or more. Now, given that you have stated that it only takes 30 minutes to write a document that is ready for publication as an RFC, you may not share that view, but my opinion has been honed over experience in different working groups over the years where I've seen it happen. regards, Dan. From nobody Mon Mar 31 02:07:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4491A098B for ; Mon, 31 Mar 2014 02:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxytF6K6c9Lp for ; Mon, 31 Mar 2014 02:07:25 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 946C01A0987 for ; Mon, 31 Mar 2014 02:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1396256843; x=1427792843; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=65t/ijzbmGYYXInNJ6e7JwzWsbpMMk7ogo3d0nlJpxc=; b=YnbPdyyxgqc2kcR2O4SAO1NlozrcYyLPXg8CFRaLUHT6OlDffkCxq4jZ u+z6GjXrYQWxYp1mr5NcI9UKh2BF77zy+2WFUK0HkRS5e2ZgMwU2a8NHJ NYk4FsZ4P/Cnmf5zb+CsybDUXcFNyhY3fYxuJ6mSa6uiwbMZP++wNk5lc 8=; X-IronPort-AV: E=Sophos;i="4.97,763,1389697200"; d="scan'208";a="243974859" 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 Mar 2014 22:07:21 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.70]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Mon, 31 Mar 2014 22:07:20 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] TLS 1.3 process Thread-Index: Ac9MwJ+ALholVoHvSPeY950uwKZ7AQ== Date: Mon, 31 Mar 2014 09:07:21 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738A33C4A8@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6dRy4GnG5xyLM0uhHgSTMA48Ekw Subject: Re: [TLS] TLS 1.3 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: Mon, 31 Mar 2014 09:07:28 -0000 Dan Harkins writes:=0A= =0A= >[...]=0A= =0A= I think Bill Frantz has already responded to everything in your message...= =0A= =0A= Peter.=0A= From nobody Mon Mar 31 03:36:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099731A0698 for ; Mon, 31 Mar 2014 03:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, 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 RtyJXkgeLoJ3 for ; Mon, 31 Mar 2014 03:36:02 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id C1C251A0678 for ; Mon, 31 Mar 2014 03:36:01 -0700 (PDT) Received: (qmail 12493 invoked by uid 1000); 31 Mar 2014 10:35:57 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 31 Mar 2014 11:35:57 +0100 Message-ID: <5339450D.3060306@comodo.com> Date: Mon, 31 Mar 2014 11:35:57 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Andrei Popov , Daniel Kahn Gillmor , Marsh Ray , Martin Thomson References: <31dba3a928d145c6835d4bbcfa603354@BY2PR03MB074.namprd03.prod.outlook.com> <5335785F.2070104@fifthhorseman.net> <368f5b8e9f9b49d1b8b1e2600a1b8a49@BL2PR03MB419.namprd03.prod.outlook.com> In-Reply-To: <368f5b8e9f9b49d1b8b1e2600a1b8a49@BL2PR03MB419.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k6TANPZGvXR4mrGPaQPLY5cyjXI Cc: "tls@ietf.org" Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 10:36:05 -0000 On 28/03/14 19:03, Andrei Popov wrote: >> did SChannel ever support classic DHE with RSA authentication? > > "Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update spring 2014" adds a couple of DHE_RSA cipher suites: > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 Andrei, may we therefore assume that "Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update spring 2014" will also add these 2 ciphers... TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA256 ? (Marsh wrote "Historically we have opted to provide ECDHE *in place of* classic DHE". I'm trying to figure out if this is still your approach, or if you're now doing the opposite!) Thanks. > Without this update, schannel supports DHE_DSS (admittedly, not the most widely used auth). > > Cheers, > > Andrei > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor > Sent: Friday, March 28, 2014 6:26 AM > To: Marsh Ray; Martin Thomson > Cc: tls@ietf.org > Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) > > On 03/27/2014 08:17 PM, Marsh Ray wrote: >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >>> >>> On 27 March 2014 16:55, Marsh Ray wrote: >>>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Alyssa Rowan >>>>> >>>>> Show of hands: who *really* wants to deploy 2048-bit (or above) DHE, when they could have curve25519 instead? >>>> >>>> The general consensus at Microsoft is that we like ECDHE much better than the classic DHE. >>> >>> I think that this is the general trend, but is it so bad that you would want to prohibit DHE? >> >> Historically we have opted to provide ECDHE *in place of* classic DHE. > > did SChannel ever support classic DHE with RSA authentication? > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=vs.85%29.aspx > > suggests that XP and win2003 (which, afaict, were what immediately preceded vista) does not have DHE. So it looks like ECDHE was just added, but "classic DHE" wasn't in SChannel in the first place, which doesn't sound like ECDHE is "in place of" DHE to me. > > or am i misreading the documentation? > > --dkg > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Mon Mar 31 07:24:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045EC1A084D for ; Mon, 31 Mar 2014 07:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciZXUR8P0D1l for ; Mon, 31 Mar 2014 07:24:53 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) by ietfa.amsl.com (Postfix) with ESMTP id 71C821A0849 for ; Mon, 31 Mar 2014 07:24:53 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 9so3271026ykp.38 for ; Mon, 31 Mar 2014 07:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=D1yPQcDR92d2RgxKy59kwZ6O5bK7rnE9Rm2aZhY3JTQ=; b=MvMDaFiGElcremtYYUm9OGyGlxBlRBJavEVJGuWpfz2GHZdX/bHvKpZ3DtTH+3TURy heOhJMtH/81+0eOy7zgi8yUKQXPKZOjaiYY10SqG0zN5YGbuDEoN3NIAsb4H+Wj3Cb6v bJnzNPdXpyWgmARJuVVZ4HVDyHwwWnW5cgq+M3Dio5MNiUGEpdYk/ztUkyt6gsOPCgov H/Pk9ZLzqUDnyjcLvrbgxkw4iMaAzfal1+U3VBfImdl7J/18g4cW9NEmF+J1k+Mv2xax H+79t0Ekzd9AQ0XeqaHXIYMNHWb5VqkG/GNhDOxDt4uSpu6IpiQoeL5hi1lPomnLYbMU qTfQ== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr36370314yhi.4.1396275890150; Mon, 31 Mar 2014 07:24:50 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 31 Mar 2014 07:24:50 -0700 (PDT) Date: Mon, 31 Mar 2014 07:24:50 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AVxdgzDY3WS1Gt8xZEc7KUg2MGQ Subject: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 14:24:55 -0000 Dear all, Reuters reports "The NSA played a significant role in the origins of Extended Random. The authors of the 2008 paper on the protocol were Margaret Salter, technical director of the NSA's defensive Information Assurance Directorate, and an outside expert named Eric Rescorla. Rescorla, who has advocated greater encryption of all Web traffic, works for Mozilla, maker of the Firefox web browser. He and Mozilla declined to comment. Salter did not respond to requests for comment." I'd like some explanation, particularly given that draft-rescorla-tls-extended-random-02 contains nothing resembling an explanation for why the randomness needs to be extended if ECDHE is being used, which it is on all DoD applications. Furthermore, this confirms that the IAD inserts backdoors into products. For those who aren't aware, extended random makes it easier to exploit the Dual EC PRNG. Sincerely, Watson Ladd From nobody Mon Mar 31 07:28:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38ABA1A6EFB for ; Mon, 31 Mar 2014 07:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7FMsyvi76X7 for ; Mon, 31 Mar 2014 07:28:10 -0700 (PDT) Received: from mx05.mykolab.com (mx01.mykolab.com [95.128.36.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638151A6EF7 for ; Mon, 31 Mar 2014 07:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at kolabsys.net Sender: fergdawgster@mykolab.com Message-ID: <53397B6F.9050806@mykolab.com> Date: Mon, 31 Mar 2014 07:27:59 -0700 From: Paul Ferguson Organization: Clowns R. Mofos To: Watson Ladd References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SnNBOCB-s_jEwbZZqsNWLW8g4zE Cc: "tls@ietf.org" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 14:28:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/31/2014 7:24 AM, Watson Ladd wrote: > Dear all, Reuters reports "The NSA played a significant role in the > origins of Extended Random. The authors of the 2008 paper on the > protocol were Margaret Salter, technical director of the NSA's > defensive Information Assurance Directorate, and an outside expert > named Eric Rescorla. > > Rescorla, who has advocated greater encryption of all Web traffic, > works for Mozilla, maker of the Firefox web browser. He and > Mozilla declined to comment. Salter did not respond to requests for > comment." > Please provide a pointer for this reference. Thanks, - - ferg > I'd like some explanation, particularly given that > draft-rescorla-tls-extended-random-02 contains nothing resembling > an explanation for why the randomness needs to be extended if ECDHE > is being used, which it is on all DoD applications. Furthermore, > this confirms that the IAD inserts backdoors into products. > > For those who aren't aware, extended random makes it easier to > exploit the Dual EC PRNG. > > Sincerely, Watson Ladd > > _______________________________________________ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlM5e28ACgkQKJasdVTchbLp8AD+I+MOgHSlv9trQsMNBPufPG78 GvqeXGJCZEbfaUIQZZcA/RMXavgDbx33StTXoAVjgxG+xjzdtGh0CDh68g/nH4Gu =pOId -----END PGP SIGNATURE----- From nobody Mon Mar 31 07:30:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF111A6EFB for ; Mon, 31 Mar 2014 07:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWaE3mB_U33P for ; Mon, 31 Mar 2014 07:29:58 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2320F1A6F02 for ; Mon, 31 Mar 2014 07:29:58 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id id10so8191391vcb.26 for ; Mon, 31 Mar 2014 07:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HvNx/98fJ3UgnLBdqeEcTRutbwLUZzMWTMkY3bfb1EI=; b=DZbsv1kO3vYQYKCE0d6l3XdczaLRpIQ1UQeW7FxjO8TOnkY2VLhGOXMDRgAVtHCl6P 8bEGAUkfnNubwoJInsYpkLLMKbBIX26VAqmNKkdzC5Yeo58lif0CxSU8raBP/hLqFI+I 2UoiIVGH40GXAdLyuAstbptVy5U8Hpa+Q0zs/PhvhPjqFlGzDtYNTR+g6Y3d8xIzt+Yn tCMai42up++roLsJczv3sLHyLrL8HMdGGCYccktDYqM/KBG/c+Kri0IXslbLa7i0rV7O QuB0C+IohYdpch6ztzT1VcgCJKmun45g2AF1SAWF7QNFLH6w68YAJrKVCDT2igIWvvAq cBBA== 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=HvNx/98fJ3UgnLBdqeEcTRutbwLUZzMWTMkY3bfb1EI=; b=LZBY7f/bJcWw3S0twB9OFfGKDLYYwbgctVSiXyrpKPigTndn+frQ5yDRnkt3G9l/SA n/6q03GEHnrytln2mnqKUeLmczDtZvwYJxCWkZc4R1bN6dZsSa0z52nTZXTJKH/TIZJt FUQtF3nRsk3vYJjGj+I5VxwZMo0TxxVZUECkucMlxbeJCihm3oluFjF+/H4IGqoEu3iD K3HEEZHzRPrTelipqO1jwVb0Io0VaA8KivuKvYD42KpCKXemdeHBm2W94plw3NwztVfz 0Kbi2Stiul9drlXGWLgebWJd875tEDPuXCxHGEuSD9KgfYn2KG85+22fQTjCh8xKLz/D rzNQ== X-Gm-Message-State: ALoCoQlJGbqs3rbBofQzCTSU5xwNJ84RBFT5xPgzqSpwQO0KePgX6NyoWnDjFovrmCtlMNdIqxG5Ei7qVE5RIW5/Nx0nu654h2MQ4yAwGMdp+Cytg0iwc51aCo1oCnNbn96g3zmriDZIiuEz28pmn0+lvY6X3p7T0Z9QedK9CbmINh65pxXzU5V4a4fGkPRggnf/XWHtidSw X-Received: by 10.58.220.161 with SMTP id px1mr24495196vec.13.1396276194717; Mon, 31 Mar 2014 07:29:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.225 with HTTP; Mon, 31 Mar 2014 07:29:34 -0700 (PDT) In-Reply-To: <53397B6F.9050806@mykolab.com> References: <53397B6F.9050806@mykolab.com> From: Adam Langley Date: Mon, 31 Mar 2014 10:29:34 -0400 Message-ID: To: Paul Ferguson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XcAkX-t1AfGr2A6RR2-mLBp9lbM Cc: "tls@ietf.org" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 14:30:00 -0000 On Mon, Mar 31, 2014 at 10:27 AM, Paul Ferguson wrote: >> Rescorla, who has advocated greater encryption of all Web traffic, >> works for Mozilla, maker of the Firefox web browser. He and >> Mozilla declined to comment. Salter did not respond to requests for >> comment." >> > Please provide a pointer for this reference. http://www.reuters.com/article/2014/03/31/us-usa-security-nsa-rsa-idUSBREA2U0TY20140331 I believe. Note that it's reporting on a paper that has yet(?) to be made public. Cheers AGL From nobody Mon Mar 31 07:36:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25781A6F1F for ; Mon, 31 Mar 2014 07:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MfmXNnuJ-d-M for ; Mon, 31 Mar 2014 07:36:26 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id 112781A6F1A for ; Mon, 31 Mar 2014 07:36:25 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id z60so228343qgd.28 for ; Mon, 31 Mar 2014 07:36:22 -0700 (PDT) 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=Ewx8P90qLNt2P5n8fr/7EclhjTL/9AQ7LkzPU80Zjlw=; b=GCwDUNTxeURS6LwvdOpC8u+8NOTXRWonxPiOJQgblmPi+HNxz1iYAJK4lLVdIPWoQo qgIw0EKSzAQJ8x1Z+NTZiQBQSEoWgiCwdS/pFR+1iXBP4TzET1OHYewMjqQSx20QwH2k 7bWCBQ9iCwzV4dG52BldFBBdOE5+6V6wQG9p9plJU9/NKcqBCesMD6lY+XM01P0mCEEv +65DrV6Mhi/rdU3fuO6/sqvW1W4zidJfDhf/2YQSCxaJiJ5is0s46gcBfOitG3w7E132 Kuw+XAT7crGMg+69OVuO0NolhCEeNjw06s/AXi3JANqUE104JLSTrGzLyudS8ZKUbl5l nl9A== X-Gm-Message-State: ALoCoQn2MiLqGmOFYrZKbifdXaSydKRjhO/OJxY+ul3sKtK4s6orK3NeO2kX1ZXyeVI6dD0VEWuD X-Received: by 10.140.98.233 with SMTP id o96mr7285494qge.86.1396276582595; Mon, 31 Mar 2014 07:36:22 -0700 (PDT) Received: from zbox.pahtak.org (c-68-48-196-126.hsd1.md.comcast.net. [68.48.196.126]) by mx.google.com with ESMTPSA id j7sm28740212qab.27.2014.03.31.07.36.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Mar 2014 07:36:22 -0700 (PDT) Received: from polaris.isi.jhu.edu (polaris.isi.jhu.edu [128.220.247.217]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 0B636AC28B0; Mon, 31 Mar 2014 10:36:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Stephen Checkoway In-Reply-To: Date: Mon, 31 Mar 2014 10:36:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Watson Ladd X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NOKwi0vvoYovXlboqA9Vv6qJ1B0 Cc: "tls@ietf.org" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 14:36:28 -0000 On Mar 31, 2014, at 10:24 AM, Watson Ladd wrote: > Furthermore, this confirms that the IAD inserts backdoors into = products. Our results say nothing about whether NIST, the NSA, or = anyone else inserted a backdoor into dual ec. Instead, they say that if = you know the relationship between P and Q, then some TLS implementations = can be broken at a given cost. The precise results are more nuanced than = that. You can read the website for a summary or the paper for the = details. --=20 Stephen Checkoway From nobody Mon Mar 31 07:39:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCF21A6F27 for ; Mon, 31 Mar 2014 07:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JrsxxmvFYzY for ; Mon, 31 Mar 2014 07:39:19 -0700 (PDT) Received: from mx05.mykolab.com (mx01.mykolab.com [95.128.36.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19C81A6F1B for ; Mon, 31 Mar 2014 07:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at kolabsys.net Sender: fergdawgster@mykolab.com Message-ID: <53397E0C.9000504@mykolab.com> Date: Mon, 31 Mar 2014 07:39:08 -0700 From: Paul Ferguson Organization: Clowns R. Mofos To: Adam Langley References: <53397B6F.9050806@mykolab.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DhrAWkwayGPyTyLTaJYmdeihmzU Cc: "tls@ietf.org" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 14:39:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/31/2014 7:29 AM, Adam Langley wrote: > On Mon, Mar 31, 2014 at 10:27 AM, Paul Ferguson > wrote: >>> Rescorla, who has advocated greater encryption of all Web >>> traffic, works for Mozilla, maker of the Firefox web browser. >>> He and Mozilla declined to comment. Salter did not respond to >>> requests for comment." >>> >> Please provide a pointer for this reference. > > http://www.reuters.com/article/2014/03/31/us-usa-security-nsa-rsa-idUSBREA2U0TY20140331 > > I believe. > > Note that it's reporting on a paper that has yet(?) to be made > public. > I would very much appreciate a pointer to the paper when it becomes available. Thanks, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlM5fgwACgkQKJasdVTchbJQvAEAtnQOq75FPNTYU6jEFz+nq9cb l4X1qb8249sdIOFBzy8BAIaGmFeLy6VI+bLAE51hKUwdUxWNhXC6e5XSJ8qW1EpW =vZE+ -----END PGP SIGNATURE----- From nobody Mon Mar 31 07:41:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578E91A6F26 for ; Mon, 31 Mar 2014 07:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uMQ5lYGx-gQ4 for ; Mon, 31 Mar 2014 07:41:13 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C21BF1A0A24 for ; Mon, 31 Mar 2014 07:41:13 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id z10so8050411pdj.4 for ; Mon, 31 Mar 2014 07:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aNEgViSX9rjN9U79wkExIPTb+j8g+ulNoiM/kxcls9E=; b=Nrmt1BXgLSsD7eayB/dOdc25aYLPtK5NU/xwA/yqNV90Y5k2ZF5KYj0jpUPSiZM+g/ oKofxva37/b61JF+SII9W425m2AfY+4eI/rfEAu4I39P/+zbZwWxxoMzcgFceDPYFf8v OYRccLVQXioxEIs66ipyeHhdMg/Si4KAN9Xi0= 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=aNEgViSX9rjN9U79wkExIPTb+j8g+ulNoiM/kxcls9E=; b=EghnKVW7ce0r/QsM88iitoZ9MjkQyQKXZG91i6NNL5umL4xSZhSALOOG4QFEubbhcs cF9qYzUoQlb+UIL+RDwOVoeIwelDtPiRBbZnNq3LmaNNppKQ+6h8yNCJczwGUQ4m5dEK MYHIv9VjC66arwgumgfG5XUs9yDNJyDBpjJWidF9k71n8VX9BRVEve1seZYbirCTcaaC 2mFkKQtJY4lATqjSuzG3140/Uc8qLPqqoR3ZeiwlKOzadhZRTFzNpMAvgh/9ptTN+iT0 DXmoH4pDOQSQt5KpRpFK1HSU9Tyy3+hGU7A7CurfLLqRL2mlF2MRa5xXld/jkAs1uGNn OG5g== X-Gm-Message-State: ALoCoQlJ9UUtIMIwIqj+6URFQADcPip7P/VMpfSDOqI2G7Z5x2lGrBQB5aRDM6HhOdS3Htmf3A6r X-Received: by 10.66.140.104 with SMTP id rf8mr9600414pab.107.1396276869436; Mon, 31 Mar 2014 07:41:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.198.68 with HTTP; Mon, 31 Mar 2014 07:40:49 -0700 (PDT) In-Reply-To: <53397E0C.9000504@mykolab.com> References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> From: Tom Ritter Date: Mon, 31 Mar 2014 10:40:49 -0400 Message-ID: To: Paul Ferguson Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/synefW4b_6_SyKuF4WYckIRebOk Cc: "tls@ietf.org" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 14:41:15 -0000 Looks like this has the technical details: http://dualec.org/ -tom From nobody Mon Mar 31 07:45:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0941A0A24 for ; Mon, 31 Mar 2014 07:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjGEJH8-6i4g for ; Mon, 31 Mar 2014 07:45:28 -0700 (PDT) Received: from mx05.mykolab.com (mx01.mykolab.com [95.128.36.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABD61A0849 for ; Mon, 31 Mar 2014 07:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at kolabsys.net Sender: fergdawgster@mykolab.com Message-ID: <53397F7C.2060603@mykolab.com> Date: Mon, 31 Mar 2014 07:45:16 -0700 From: Paul Ferguson Organization: Clowns R. Mofos To: Tom Ritter References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KqsXDWTbfALVEEheDNiNhyLSATM Cc: "tls@ietf.org" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 14:45:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/31/2014 7:40 AM, Tom Ritter wrote: > Looks like this has the technical details: http://dualec.org/ > Gracias. - - ferg > -tom > > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlM5f3wACgkQKJasdVTchbKYNgEAiwR5zR2qfSRfdEkXQx7CihyY QD3xZG9bkx8+40Gc+BYA/Avz/59WC1sv8KodlV4Z81rJqMF8uKrrxn2A6SR80lgC =NxYj -----END PGP SIGNATURE----- From nobody Mon Mar 31 08:33:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782151A087F for ; Mon, 31 Mar 2014 08:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoasmTR-2gYv for ; Mon, 31 Mar 2014 08:33:16 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 36DEF1A0549 for ; Mon, 31 Mar 2014 08:33:16 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id as1so7601341iec.25 for ; Mon, 31 Mar 2014 08:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PgF27+ezbuctcNjHGgr5T8ggTJXjGuqPfvZG06xbKng=; b=fMemhH9qiyoIqBYa552McF70Y0SvADD/0Japg3x0jRWgCvwV97gUEp55ZbpIV9wv93 ZaSMIW2Kzj9IGUs3h8S2KnQuKSGcao0mcHQS0Kbr8OXGw6OUDtcYQ0oyr6xVLgzXO0wm 8xcr5MvPU19swNSQLucEI+cuVJOidjJtxZ3UaISGUOQWG/sqVNjoJYadAAz61edaoEIE sFIkD1bJ7/C2kUaSifNdxotv/U0mkqZdtAJWToUP51XxqqZBTy6vBcvqP79Y/0YRUx+u 8AX671G5xIsM9dX14jP/PSaGzFIPmNrarQeszGRLb9d2lM/560S3rkqxOeSFth0ak81n 0FaQ== X-Received: by 10.42.27.136 with SMTP id j8mr4856467icc.69.1396279992881; Mon, 31 Mar 2014 08:33:12 -0700 (PDT) Received: from [192.168.1.104] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id z5sm25886737igl.13.2014.03.31.08.33.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Mar 2014 08:33:11 -0700 (PDT) Message-ID: <53398AB3.9090102@gmail.com> Date: Mon, 31 Mar 2014 11:33:07 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Paul Ferguson , Tom Ritter References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> <53397F7C.2060603@mykolab.com> In-Reply-To: <53397F7C.2060603@mykolab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JDEEE1O0KjP6SsFeX3JKzZkcyPo Cc: "tls@ietf.org" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 15:33:18 -0000 Dear colleagues: Not sure what is new here. The paper (with an impressive list of nine (!) co-authors) seems to be simply a validation of results already described in the Crypto 2007 rump session paper by Ferguson et al and in the teachings of a 2005 US patent application. Best regards, Rene On 3/31/2014 10:45 AM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 3/31/2014 7:40 AM, Tom Ritter wrote: > >> Looks like this has the technical details: http://dualec.org/ >> > Gracias. > > - - ferg > >> -tom >> >> > > - -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlM5f3wACgkQKJasdVTchbKYNgEAiwR5zR2qfSRfdEkXQx7CihyY > QD3xZG9bkx8+40Gc+BYA/Avz/59WC1sv8KodlV4Z81rJqMF8uKrrxn2A6SR80lgC > =NxYj > -----END PGP SIGNATURE----- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Mon Mar 31 08:47:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF0D1A0884 for ; Mon, 31 Mar 2014 08:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4iFDfWPYVMB for ; Mon, 31 Mar 2014 08:47:32 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7971A6F6A for ; Mon, 31 Mar 2014 08:46:28 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id w7so9014065qcr.25 for ; Mon, 31 Mar 2014 08:46:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a0wdyXY9wjQ7F8wWRi+1HstQnzpTFoilzHNh+LEPP1c=; b=CNsHk8HmJj11berYSKMIFTHAPHLxj+ApW0hTFSRP44cWAU0wGiK8eesusko4/x4Vcl Zh49S21KTN/91U5UkrY89lmttRoJ8NkBYMxT3DFNWSXIDZc8mk9ulIU9sAy2PslPtsQu EePx1vc8Y33/LufMFuzfmH6u2uSVkELk52NcLZy4rl+BMDMAgHe3RLqMHqq3mLQrCe3L UNRFfRslErT6zNDh0AIUHYv3ceFhG14UTcxn5SHgv0Wcu2bnVCpq3limFAvkqooOlALB X+b83N2Ke4Pwcmk+TtfIiMqP8U7ci1iouWRKw5kpBnSrd2qDy/c9zPy82OoKfaXsH1DD zDRQ== X-Gm-Message-State: ALoCoQkqB9qTJtk2d+Z/VYog2ukfASJ2sScNv9CxKLUa/fL5Tx+RusxX405W+yT6rO4AiTRjjxB1 MIME-Version: 1.0 X-Received: by 10.229.58.68 with SMTP id f4mr9173733qch.18.1396280784742; Mon, 31 Mar 2014 08:46:24 -0700 (PDT) Received: by 10.140.100.204 with HTTP; Mon, 31 Mar 2014 08:46:24 -0700 (PDT) X-Originating-IP: [128.204.203.103] In-Reply-To: <53398AB3.9090102@gmail.com> References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> <53397F7C.2060603@mykolab.com> <53398AB3.9090102@gmail.com> Date: Mon, 31 Mar 2014 15:46:24 +0000 Message-ID: From: Jacob Appelbaum To: Rene Struik Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F9HL8pF2e_K9kZGyZrwfColes9c Cc: "tls@ietf.org" , "D. J. Bernstein" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 15:47:34 -0000 On 3/31/14, Rene Struik wrote: > Dear colleagues: > > Not sure what is new here. The paper (with an impressive list of nine > (!) co-authors) seems to be simply a validation of results already > described in the Crypto 2007 rump session paper by Ferguson et al and in > the teachings of a 2005 US patent application. > I was unaware that Ferguson et al did an internet wide scan or found the speedup for the vulnerabilities? It seems to me that this work confirms and expands on the previous research. The intentions for such an implemention are also seemingly confirmed thanks to the bravery of the whistleblower Edward Snowden. Context is everything. All the best, Jacob From nobody Mon Mar 31 09:06:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB841A6F21 for ; Mon, 31 Mar 2014 09:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhEUSuEALIOH for ; Mon, 31 Mar 2014 09:06:36 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 358DB1A6F0B for ; Mon, 31 Mar 2014 09:06:36 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so6199594wgh.29 for ; Mon, 31 Mar 2014 09:06:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HmIEfA9TLwA7PaSpYBvUfzchOeiwsczfGff3FvShtPM=; b=WaYUnj/nGiuUKdGIabibRzb3yQKZIN9IH7Bk6aSq5SRcZ8EbFachOuupc4e87xTHp+ /JoPvT7B6p1CPmBd+NcEf8u2uDff9+JXc4nNWQKP+063J6GWDhlMwUu+kx5ZlC3N/kyN Xd+61oEybjBKJMXIAuOSI9oPozob2UO4hNhW0KRDOOwqZLpQ6Z3cFRfzo/RnMYJbA6jJ nd2YaWZ7C+6r86nGn+swYmi0a2Nl9b6v+WsNdI+I+VBgeITBRnRITAGnZ82NWqt294Uz AN1mgK5AHEyPACDSaA1TJn7Lq6KAH2KGIF0tivvFQ26P9S85tGcc0Gqe7cwU0zNgQW42 flXw== X-Gm-Message-State: ALoCoQmbllYmXlxV6jeY7UDxtJYLjgDyt3rvzzPV28yGBYV0WE43k5NnFwCtsKHb6Ju8JFv2c4mX MIME-Version: 1.0 X-Received: by 10.180.9.42 with SMTP id w10mr13447353wia.20.1396281984316; Mon, 31 Mar 2014 09:06:24 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Mon, 31 Mar 2014 09:06:24 -0700 (PDT) X-Originating-IP: [184.23.29.222] In-Reply-To: <53398AB3.9090102@gmail.com> References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> <53397F7C.2060603@mykolab.com> <53398AB3.9090102@gmail.com> Date: Mon, 31 Mar 2014 09:06:24 -0700 Message-ID: From: Trevor Perrin To: Rene Struik Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wUu6M-bvw9fkHSqd2v-8jkdisO0 Cc: "tls@ietf.org" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 16:06:39 -0000 Hi Rene, The revelation that NSA used this Working Group in an attempt to promote TLS extensions which amplify the backdoor is new: https://datatracker.ietf.org/doc/draft-rescorla-tls-opaque-prf-input/ https://datatracker.ietf.org/doc/draft-rescorla-tls-extended-random/ Trevor On Mon, Mar 31, 2014 at 8:33 AM, Rene Struik wrote: > Dear colleagues: > > Not sure what is new here. The paper (with an impressive list of nine (!) > co-authors) seems to be simply a validation of results already described in > the Crypto 2007 rump session paper by Ferguson et al and in the teachings of > a 2005 US patent application. > > Best regards, Rene > > > > On 3/31/2014 10:45 AM, Paul Ferguson wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 3/31/2014 7:40 AM, Tom Ritter wrote: >> >>> Looks like this has the technical details: http://dualec.org/ >>> >> Gracias. >> >> - - ferg >> >>> -tom >>> >>> >> >> - -- Paul Ferguson >> VP Threat Intelligence, IID >> PGP Public Key ID: 0x54DC85B2 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (MingW32) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iF4EAREIAAYFAlM5f3wACgkQKJasdVTchbKYNgEAiwR5zR2qfSRfdEkXQx7CihyY >> QD3xZG9bkx8+40Gc+BYA/Avz/59WC1sv8KodlV4Z81rJqMF8uKrrxn2A6SR80lgC >> =NxYj >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> 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 nobody Mon Mar 31 09:22:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199CF1A0893 for ; Mon, 31 Mar 2014 09:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpUNLLPMdKNe for ; Mon, 31 Mar 2014 09:22:43 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id E610C1A0892 for ; Mon, 31 Mar 2014 09:22:42 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id m20so9147117qcx.21 for ; Mon, 31 Mar 2014 09:22:39 -0700 (PDT) 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=WH44a9dT/V+nNvDvY1T3TO3zotCEJhDdQ5ftZhqhGwg=; b=aGh2DTWakQZ8l6+ZwdW9OUb3QrOmCCCq7fBk/V8Oi6HCcVCj7U2xD01qOFERe5aT4q 8zrXMtwvWI+AfYiZTyayVSLiCceMy0VVy3bdDCPoBXnJt62uifSkO11lS3aZGXQFfSzx SYjXUf5C0hJlT65p81mDQaNyh5grzPjDVQujmiCX6IuGEfdwn8DD3HMa+CcilZDkbcjz 6fPHvZ2gdvPWgyJDkQ865jjsMRqtS4klW135r2TNNMc6/jf84oUiRjd6D1qdcjeDEUAG yoPAiAdZRzXn5P3IMq/y3uz5T/j6OedldFjkIa0clpAjduyhU7MaQO2paN9dhTW7lm2C Wcdg== X-Gm-Message-State: ALoCoQksmzPOBtdKx8HypU1vWhQDSWdoJrJh+QTFKDs7urkIxPn9UTeBNrkpuLf+9Aah1eA2Xc3k X-Received: by 10.224.29.4 with SMTP id o4mr9702652qac.55.1396282959544; Mon, 31 Mar 2014 09:22:39 -0700 (PDT) Received: from zbox.pahtak.org (c-68-48-196-126.hsd1.md.comcast.net. [68.48.196.126]) by mx.google.com with ESMTPSA id v75sm20121032qge.6.2014.03.31.09.22.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Mar 2014 09:22:39 -0700 (PDT) Received: from polaris.isi.jhu.edu (polaris.isi.jhu.edu [128.220.247.217]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 2941DAC28B0; Mon, 31 Mar 2014 12:22:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Stephen Checkoway In-Reply-To: Date: Mon, 31 Mar 2014 12:22:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4564B6F0-EAE8-457F-8698-ED929F4DDA01@pahtak.org> References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> <53397F7C.2060603@mykolab.com> <53398AB3.9090102@gmail.com> To: Trevor Perrin X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/A7avZaeq1eYWBWO1rs5m2Xz8a5s Cc: "tls@ietf.org" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 16:22:49 -0000 Hi all, I can't speak to anyone's intentions, but note that these aren't the = only I-Ds that add more randomness. As described in our paper, = = is quite similar. The idea of adding more random bits seems to have been fairly popular in = the 2006-2010 timeframe. There may be more proposals to do this, for example using = , that I missed. S On Mar 31, 2014, at 12:06 PM, Trevor Perrin wrote: > Hi Rene, >=20 > The revelation that NSA used this Working Group in an attempt to > promote TLS extensions which amplify the backdoor is new: >=20 > https://datatracker.ietf.org/doc/draft-rescorla-tls-opaque-prf-input/ > https://datatracker.ietf.org/doc/draft-rescorla-tls-extended-random/ >=20 >=20 > Trevor >=20 >=20 > On Mon, Mar 31, 2014 at 8:33 AM, Rene Struik = wrote: >> Dear colleagues: >>=20 >> Not sure what is new here. The paper (with an impressive list of nine = (!) >> co-authors) seems to be simply a validation of results already = described in >> the Crypto 2007 rump session paper by Ferguson et al and in the = teachings of >> a 2005 US patent application. >>=20 >> Best regards, Rene >>=20 >>=20 >>=20 >> On 3/31/2014 10:45 AM, Paul Ferguson wrote: >>>=20 >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>>=20 >>> On 3/31/2014 7:40 AM, Tom Ritter wrote: >>>=20 >>>> Looks like this has the technical details: http://dualec.org/ >>>>=20 >>> Gracias. >>>=20 >>> - - ferg >>>=20 >>>> -tom >>>>=20 >>>>=20 >>>=20 >>> - -- Paul Ferguson >>> VP Threat Intelligence, IID >>> PGP Public Key ID: 0x54DC85B2 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2.0.22 (MingW32) >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>=20 >>> iF4EAREIAAYFAlM5f3wACgkQKJasdVTchbKYNgEAiwR5zR2qfSRfdEkXQx7CihyY >>> QD3xZG9bkx8+40Gc+BYA/Avz/59WC1sv8KodlV4Z81rJqMF8uKrrxn2A6SR80lgC >>> =3DNxYj >>> -----END PGP SIGNATURE----- >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >>=20 >>=20 >> -- >> email: rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>=20 >>=20 >> _______________________________________________ >> 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 >=20 --=20 Stephen Checkoway From nobody Mon Mar 31 09:56:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2835C1A6F0B for ; Mon, 31 Mar 2014 09:56:03 -0700 (PDT) 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 Zy-nHR-q6KyS for ; Mon, 31 Mar 2014 09:56:01 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 39B1D1A089A for ; Mon, 31 Mar 2014 09:56:01 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8F8EDA888012; Mon, 31 Mar 2014 09:55:57 -0700 (PDT) Received: from 156.39.128.195 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 31 Mar 2014 09:55:58 -0700 (PDT) Message-ID: <90f23b058bc25f4c0701d710270d443f.squirrel@www.trepanning.net> In-Reply-To: References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> <53397F7C.2060603@mykolab.com> <53398AB3.9090102@gmail.com> Date: Mon, 31 Mar 2014 09:55:58 -0700 (PDT) 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bmEc9Q9uDBkviTqbOB5xQ78yOD0 Cc: "tls@ietf.org" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 16:56:03 -0000 Hi Trevor, On Mon, March 31, 2014 9:06 am, Trevor Perrin wrote: > Hi Rene, > > The revelation that NSA used this Working Group in an attempt to > promote TLS extensions which amplify the backdoor is new: > > https://datatracker.ietf.org/doc/draft-rescorla-tls-opaque-prf-input/ > https://datatracker.ietf.org/doc/draft-rescorla-tls-extended-random/ By "backdoor" do you mean Dual_EC:DRBG? If so, what do you mean by "amplify the backdoor"? Dan. > > Trevor > > > On Mon, Mar 31, 2014 at 8:33 AM, Rene Struik > wrote: >> Dear colleagues: >> >> Not sure what is new here. The paper (with an impressive list of nine >> (!) >> co-authors) seems to be simply a validation of results already described >> in >> the Crypto 2007 rump session paper by Ferguson et al and in the >> teachings of >> a 2005 US patent application. >> >> Best regards, Rene >> >> >> >> On 3/31/2014 10:45 AM, Paul Ferguson wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> On 3/31/2014 7:40 AM, Tom Ritter wrote: >>> >>>> Looks like this has the technical details: http://dualec.org/ >>>> >>> Gracias. >>> >>> - - ferg >>> >>>> -tom >>>> >>>> >>> >>> - -- Paul Ferguson >>> VP Threat Intelligence, IID >>> PGP Public Key ID: 0x54DC85B2 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2.0.22 (MingW32) >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>> >>> iF4EAREIAAYFAlM5f3wACgkQKJasdVTchbKYNgEAiwR5zR2qfSRfdEkXQx7CihyY >>> QD3xZG9bkx8+40Gc+BYA/Avz/59WC1sv8KodlV4Z81rJqMF8uKrrxn2A6SR80lgC >>> =NxYj >>> -----END PGP SIGNATURE----- >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Mar 31 10:02:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864C11A089A for ; Mon, 31 Mar 2014 10:02:20 -0700 (PDT) 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 PmBtnxJgl3Zc for ; Mon, 31 Mar 2014 10:02:19 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id F072B1A6F0B for ; Mon, 31 Mar 2014 10:02:18 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 53AB3A888012; Mon, 31 Mar 2014 10:02:15 -0700 (PDT) Received: from 156.39.128.195 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 31 Mar 2014 10:02:15 -0700 (PDT) Message-ID: <5d310d4d2dfb531155171f01ebe7e570.squirrel@www.trepanning.net> In-Reply-To: <90f23b058bc25f4c0701d710270d443f.squirrel@www.trepanning.net> References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> <53397F7C.2060603@mykolab.com> <53398AB3.9090102@gmail.com> <90f23b058bc25f4c0701d710270d443f.squirrel@www.trepanning.net> Date: Mon, 31 Mar 2014 10:02:15 -0700 (PDT) From: "Dan Harkins" To: "Dan Harkins" 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bCpLURH3-l8gjIG6KtQVl4PUmRY Cc: "tls@ietf.org" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 17:02:20 -0000 Strike that; I found it. Dan. On Mon, March 31, 2014 9:55 am, Dan Harkins wrote: > > Hi Trevor, > > On Mon, March 31, 2014 9:06 am, Trevor Perrin wrote: >> Hi Rene, >> >> The revelation that NSA used this Working Group in an attempt to >> promote TLS extensions which amplify the backdoor is new: >> >> https://datatracker.ietf.org/doc/draft-rescorla-tls-opaque-prf-input/ >> https://datatracker.ietf.org/doc/draft-rescorla-tls-extended-random/ > > By "backdoor" do you mean Dual_EC:DRBG? If so, what do you mean by > "amplify the backdoor"? > > Dan. > >> >> Trevor >> >> >> On Mon, Mar 31, 2014 at 8:33 AM, Rene Struik >> wrote: >>> Dear colleagues: >>> >>> Not sure what is new here. The paper (with an impressive list of nine >>> (!) >>> co-authors) seems to be simply a validation of results already >>> described >>> in >>> the Crypto 2007 rump session paper by Ferguson et al and in the >>> teachings of >>> a 2005 US patent application. >>> >>> Best regards, Rene >>> >>> >>> >>> On 3/31/2014 10:45 AM, Paul Ferguson wrote: >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>> On 3/31/2014 7:40 AM, Tom Ritter wrote: >>>> >>>>> Looks like this has the technical details: http://dualec.org/ >>>>> >>>> Gracias. >>>> >>>> - - ferg >>>> >>>>> -tom >>>>> >>>>> >>>> >>>> - -- Paul Ferguson >>>> VP Threat Intelligence, IID >>>> PGP Public Key ID: 0x54DC85B2 >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v2.0.22 (MingW32) >>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>> >>>> iF4EAREIAAYFAlM5f3wACgkQKJasdVTchbKYNgEAiwR5zR2qfSRfdEkXQx7CihyY >>>> QD3xZG9bkx8+40Gc+BYA/Avz/59WC1sv8KodlV4Z81rJqMF8uKrrxn2A6SR80lgC >>>> =NxYj >>>> -----END PGP SIGNATURE----- >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 nobody Mon Mar 31 10:15:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5B81A6F44 for ; Mon, 31 Mar 2014 10:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXoabPpHewaL for ; Mon, 31 Mar 2014 10:15:29 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 344DD1A6F56 for ; Mon, 31 Mar 2014 10:15:21 -0700 (PDT) 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.908.10; Mon, 31 Mar 2014 17:15:16 +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.0908.008; Mon, 31 Mar 2014 17:15:16 +0000 From: Andrei Popov To: Peter Gutmann , "" Thread-Topic: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) Thread-Index: Ac9LG4WcQ7PNLxYPxkG9wW1NfjsVjwB58WTQ Date: Mon, 31 Mar 2014 17:15:15 +0000 Message-ID: <9d9167782e4b4dc0af862d9e0bde68e3@BL2PR03MB419.namprd03.prod.outlook.com> References: <9A043F3CF02CD34C8E74AC1594475C737239546F@uxcn10-6.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C737239546F@uxcn10-6.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-forefront-prvs: 0167DB5752 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(377454003)(13464003)(69226001)(83322001)(94316002)(19580405001)(81342001)(54316002)(81542001)(74502001)(19580395003)(95416001)(80976001)(95666003)(31966008)(86612001)(74366001)(74662001)(94946001)(74876001)(97336001)(63696002)(47736001)(47976001)(49866001)(4396001)(97186001)(85306002)(20776003)(54356001)(81686001)(76482001)(98676001)(87266001)(74706001)(79102001)(2656002)(15975445006)(83072002)(33646001)(93136001)(90146001)(85852003)(76576001)(59766001)(76796001)(92566001)(86362001)(77982001)(56776001)(56816005)(53806001)(50986001)(81816001)(51856001)(87936001)(93516002)(65816001)(46102001)(99286001)(80022001)(3826001)(24736002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB417; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:F8F2D1F0.2D2F9532.FEDA779C.C003DEC9.201DB; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JHtxDJHzakdCl1j0m4Mlpz0cOyo Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 17:15:32 -0000 Sorry, can't comment on features/functionality to be delivered in the futur= e, but I would not rule out the possibility of adding pre-1.2 DHE_RSA ciphe= r suites. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Peter Gutmann Sent: Friday, March 28, 2014 11:53 PM To: Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Conse= nsus on removing RSA key Transport from TLS 1.3) Andrei Popov writes: >"Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update spring 201= 4" >adds a couple of DHE_RSA cipher suites:=20 >TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 >TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 Those are all 1.2 suites with its barely-there deployment, what about addin= g pre-1.2 suites as well for the 99.whatever% market penetration the earlier = versions have? Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Mar 31 10:34:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04D61A6EF9 for ; Mon, 31 Mar 2014 10:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrNGLWNKfrc0 for ; Mon, 31 Mar 2014 10:34:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6671A07C3 for ; Mon, 31 Mar 2014 10:34:50 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) with Microsoft SMTP Server (TLS) id 15.0.898.11; Mon, 31 Mar 2014 17:34:45 +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.0908.008; Mon, 31 Mar 2014 17:34:44 +0000 From: Andrei Popov To: Rob Stradling , Daniel Kahn Gillmor , Marsh Ray , Martin Thomson Thread-Topic: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) Thread-Index: AQHPShlAQ7PNLxYPxkG9wW1NfjsVj5r1ogCAgADcR4CAAFgTMIAEL3OAgABv6EA= Date: Mon, 31 Mar 2014 17:34:44 +0000 Message-ID: References: <31dba3a928d145c6835d4bbcfa603354@BY2PR03MB074.namprd03.prod.outlook.com> <5335785F.2070104@fifthhorseman.net> <368f5b8e9f9b49d1b8b1e2600a1b8a49@BL2PR03MB419.namprd03.prod.outlook.com> <5339450D.3060306@comodo.com> In-Reply-To: <5339450D.3060306@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-forefront-prvs: 0167DB5752 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(13464003)(377454003)(479174003)(51444003)(51704005)(24454002)(56816005)(85306002)(50986001)(49866001)(47976001)(47736001)(95416001)(4396001)(20776003)(63696002)(77982001)(79102001)(92566001)(59766001)(95666003)(15202345003)(74366001)(74876001)(1511001)(99286001)(87266001)(90146001)(87936001)(2656002)(83072002)(15974865002)(33646001)(74706001)(15975445006)(80022001)(65816001)(54356001)(97186001)(81342001)(81542001)(97336001)(76482001)(94316002)(51856001)(56776001)(80976001)(93516002)(81816001)(94946001)(86612001)(86362001)(54316002)(83322001)(19580405001)(53806001)(81686001)(19580395003)(69226001)(93136001)(76576001)(98676001)(85852003)(76796001)(46102001)(74662001)(74502001)(31966008)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB074; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:C8EFF125.AEF39FE2.FDD63EB3.C307CB4B.204E4; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/l6xuQyfbG2gPkwjQkOcLp5dSKlk Cc: "tls@ietf.org" Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 17:34:53 -0000 Hi Rob, No, this update does not add new ECDHE_RSA cipher suites. However, I would = not rule out the possibility of implementing TLS_ECDHE_RSA_WITH_AES_128_GCM= _SHA256 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA*384* in a future update. (In any case, I would not read too much into "Historically we have opted to= provide ECDHE *in place of* classic DHE". IMHO, both DHE and ECDHE have th= eir place and we'll keep adding support for the cipher suites our customers= need.) Cheers, Andrei=20 -----Original Message----- From: Rob Stradling [mailto:rob.stradling@comodo.com]=20 Sent: Monday, March 31, 2014 3:36 AM To: Andrei Popov; Daniel Kahn Gillmor; Marsh Ray; Martin Thomson Cc: tls@ietf.org Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Conse= nsus on removing RSA key Transport from TLS 1.3) On 28/03/14 19:03, Andrei Popov wrote: >> did SChannel ever support classic DHE with RSA authentication? > > "Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update spring 20= 14" adds a couple of DHE_RSA cipher suites: > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 Andrei, may we therefore assume that "Windows RT 8.1, Windows 8.1, and Wind= ows Server 2012 R2 update spring 2014" will also add these 2 ciphers... TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA256 ? (Marsh wrote "Historically we have opted to provide ECDHE *in place of* cla= ssic DHE". I'm trying to figure out if this is still your approach, or if = you're now doing the opposite!) Thanks. > Without this update, schannel supports DHE_DSS (admittedly, not the most = widely used auth). > > Cheers, > > Andrei > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Daniel Kahn=20 > Gillmor > Sent: Friday, March 28, 2014 6:26 AM > To: Marsh Ray; Martin Thomson > Cc: tls@ietf.org > Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming=20 > Consensus on removing RSA key Transport from TLS 1.3) > > On 03/27/2014 08:17 PM, Marsh Ray wrote: >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >>> >>> On 27 March 2014 16:55, Marsh Ray wrote: >>>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Alyssa Rowan >>>>> >>>>> Show of hands: who *really* wants to deploy 2048-bit (or above) DHE, = when they could have curve25519 instead? >>>> >>>> The general consensus at Microsoft is that we like ECDHE much better t= han the classic DHE. >>> >>> I think that this is the general trend, but is it so bad that you would= want to prohibit DHE? >> >> Historically we have opted to provide ECDHE *in place of* classic DHE. > > did SChannel ever support classic DHE with RSA authentication? > > =20 > http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=3Dv > s.85%29.aspx > > suggests that XP and win2003 (which, afaict, were what immediately preced= ed vista) does not have DHE. So it looks like ECDHE was just added, but "c= lassic DHE" wasn't in SChannel in the first place, which doesn't sound like= ECDHE is "in place of" DHE to me. > > or am i misreading the documentation? > > --dkg > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended= solely for the use of the individual or entity to whom they are addressed.= If you have received this email in error please notify the sender by repl= ying to the e-mail containing this attachment. Replies to this email may be= monitored by COMODO for operational or business reasons. Whilst every ende= avour is taken to ensure that e-mails are free from viruses, no liability c= an be accepted and the recipient is requested to use their own virus checki= ng software. From nobody Mon Mar 31 12:04:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6671A08B4 for ; Mon, 31 Mar 2014 12:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTUZ7RBJiYDC for ; Mon, 31 Mar 2014 12:04:51 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 68E341A08B1 for ; Mon, 31 Mar 2014 12:04:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 79F44BE4D; Mon, 31 Mar 2014 20:04:47 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXCOg+NDzeLd; Mon, 31 Mar 2014 20:04:47 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 56DF2BE1C; Mon, 31 Mar 2014 20:04:47 +0100 (IST) Message-ID: <5339BC4F.10905@cs.tcd.ie> Date: Mon, 31 Mar 2014 20:04:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Checkoway , Trevor Perrin References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> <53397F7C.2060603@mykolab.com> <53398AB3.9090102@gmail.com> <4564B6F0-EAE8-457F-8698-ED929F4DDA01@pahtak.org> In-Reply-To: <4564B6F0-EAE8-457F-8698-ED929F4DDA01@pahtak.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UKxRkUZsAFzaNhiwEgs1uqkbgng Cc: "tls@ietf.org" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 19:04:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/31/2014 05:22 PM, Stephen Checkoway wrote: > There may be more proposals to do this, for example using > , that I missed. I took a quick look and didn't yet find any in Jari's RFC references thing [1] or the tools WG draft dependency thing [2] or the datatacker equivalent. [3] Not much to see in Google scholar either. [4] S. [1] http://www.arkko.com/tools/allstats/citations-rfc6358.html [2] http://www.fenron.net/~fenner/ietf/deps/viz/tls.pdf [3] https://datatracker.ietf.org/doc/rfc6358/referencedby/ [4] http://scholar.google.com/scholar?q=http%3A%2F%2Fwww.hjp.at%2Fdoc%2Frfc%2Frfc6358.html&btnG=&hl=en&as_sdt=0%2C5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJTObxOAAoJEC88hzaAX42i8N4H/jBHwqh25yd0N4myUiQx5ueE 2IgcBO0zSybs2ha9x2hSFcHIH01eNmMyl0Hbv2amJf8kft91LHcxhrrlrhpnlJLq BrXHLbuwvi8K9p0l0V3horwKiXOaPtBhK9Dtf7y7iVy48Mr8uTA2Dzrg073Tn4iW +BNJ0wZH0UfSHMFvhPGbP778r+2BcMFfSIKrm6G8svziI0hPZb8s2waakKALO3OY VHjtlFWFquN6rkvzN8u09lon7zp61suSXxlrGyc56LfFpO0mcsnQXWT/+R69ZVAO 2UUlAa6vgwbSJe6qJrd5bL9AVZlciJrutddKxoUQPvs1bcNixh7KoNxeXlb1nac= =DNwG -----END PGP SIGNATURE----- From nobody Mon Mar 31 12:13:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57ED01A6F73 for ; Mon, 31 Mar 2014 12:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRwDAMFpDf1Q for ; Mon, 31 Mar 2014 12:13:31 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 562F51A08B4 for ; Mon, 31 Mar 2014 12:13:31 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id D2DD1F3C003 for ; Mon, 31 Mar 2014 15:13:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id zZZzW4kRui2i for ; Mon, 31 Mar 2014 15:12:53 -0400 (EDT) Received: from [192.168.2.100] (pool-96-241-160-129.washdc.fios.verizon.net [96.241.160.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7AC81F3C004 for ; Mon, 31 Mar 2014 15:12:53 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <4564B6F0-EAE8-457F-8698-ED929F4DDA01@pahtak.org> Date: Mon, 31 Mar 2014 15:12:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <26D8EEDC-DE7D-4681-BE06-216DBAF55BEE@vigilsec.com> References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> <53397F7C.2060603@mykolab.com> <53398AB3.9090102@gmail.com> <4564B6F0-EAE8-457F-8698-ED929F4DDA01@pahtak.org> To: IETF TLS X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rc3VjZTlBR08PmwtCECUD9-VHyw Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 19:13:34 -0000 I'd like to make a few observations about the extended random extension. = At the time, I supported the creation of the extension. I was = concerned about one of the TLS parties having a poor random source = (which is quite different than random number generator with a backdoor). = Recall that a predictable random number generator was discovered in the = Debian release about this time [1]. It is rather scary that it took so = many months for this flaw to be noticed after it was released in = September 2006; the problem was not reported until May 2008. In this = context, I was interested in getting as enough quality bits from the = good random source into the calculation of the session values to = overcome the poor contribution from the other side. No one was talking about the possibility of the additional public random = values disclosing the state of a random number generator with a = backdoor. While that seems like a relevant question today, it was not = considered at the time. We were discussion weak random sources and = quality random sources. If a random number generator with a backdoor = was raised back then, I'm not sure it would have gotten the same = attention as today. I might have said: if you think ABC_DRNG might have = a backdoor, then use a different one instead. So the same extended random extension might have: (1) provided additional random from one other side to compensate for = poor values from the other, and at the same time (2) provided a means for a a random number generator with a backdoor to = disclose state. As the IETF decided at the time, the better answer is quality random = numbers all around. Russ [1] = http://en.wikinews.org/wiki/Predictable_random_number_generator_discovered= _in_the_Debian_version_of_OpenSSL On Mar 31, 2014, at 12:22 PM, Stephen Checkoway wrote: > Hi all, >=20 > I can't speak to anyone's intentions, but note that these aren't the = only I-Ds that add more randomness. As described in our paper, = = is quite similar. >=20 > The idea of adding more random bits seems to have been fairly popular = in the 2006-2010 timeframe. >=20 > There may be more proposals to do this, for example using = , that I missed. >=20 > S >=20 > On Mar 31, 2014, at 12:06 PM, Trevor Perrin wrote: >=20 >> Hi Rene, >>=20 >> The revelation that NSA used this Working Group in an attempt to >> promote TLS extensions which amplify the backdoor is new: >>=20 >> https://datatracker.ietf.org/doc/draft-rescorla-tls-opaque-prf-input/ >> https://datatracker.ietf.org/doc/draft-rescorla-tls-extended-random/ >>=20 >>=20 >> Trevor >>=20 >>=20 >> On Mon, Mar 31, 2014 at 8:33 AM, Rene Struik = wrote: >>> Dear colleagues: >>>=20 >>> Not sure what is new here. The paper (with an impressive list of = nine (!) >>> co-authors) seems to be simply a validation of results already = described in >>> the Crypto 2007 rump session paper by Ferguson et al and in the = teachings of >>> a 2005 US patent application. >>>=20 >>> Best regards, Rene >>>=20 >>>=20 >>>=20 >>> On 3/31/2014 10:45 AM, Paul Ferguson wrote: >>>>=20 >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>>=20 >>>> On 3/31/2014 7:40 AM, Tom Ritter wrote: >>>>=20 >>>>> Looks like this has the technical details: http://dualec.org/ >>>>>=20 >>>> Gracias. >>>>=20 >>>> - - ferg >>>>=20 >>>>> -tom >>>>>=20 >>>>>=20 >>>>=20 >>>> - -- Paul Ferguson >>>> VP Threat Intelligence, IID >>>> PGP Public Key ID: 0x54DC85B2 >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v2.0.22 (MingW32) >>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>>=20 >>>> iF4EAREIAAYFAlM5f3wACgkQKJasdVTchbKYNgEAiwR5zR2qfSRfdEkXQx7CihyY >>>> QD3xZG9bkx8+40Gc+BYA/Avz/59WC1sv8KodlV4Z81rJqMF8uKrrxn2A6SR80lgC >>>> =3DNxYj >>>> -----END PGP SIGNATURE----- >>>>=20 >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>=20 >>>=20 >>>=20 >>> -- >>> email: rstruik.ext@gmail.com | Skype: rstruik >>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >>=20 >=20 > --=20 > Stephen Checkoway >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Mar 31 16:28:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B281A0344 for ; Mon, 31 Mar 2014 16:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTyMWWdZIKY9 for ; Mon, 31 Mar 2014 16:28:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) by ietfa.amsl.com (Postfix) with ESMTP id 311631A08B4 for ; Mon, 31 Mar 2014 16:28:51 -0700 (PDT) Received: from SN2PR03MB080.namprd03.prod.outlook.com (10.255.175.156) by SN2PR03MB079.namprd03.prod.outlook.com (10.255.175.155) with Microsoft SMTP Server (TLS) id 15.0.898.11; Mon, 31 Mar 2014 23:28:47 +0000 Received: from SN2PR03MB080.namprd03.prod.outlook.com ([169.254.15.251]) by SN2PR03MB080.namprd03.prod.outlook.com ([169.254.15.231]) with mapi id 15.00.0898.005; Mon, 31 Mar 2014 23:28:46 +0000 From: Marsh Ray To: Russ Housley , IETF TLS Thread-Topic: [TLS] Extended random is NSA backdoor Thread-Index: AQHPTO0B6+f3VS8ZHEG0y3NBGk2uOZr7QPqAgAAAcQCAAAKsAIAAAHmAgAABPgCAAA1fgIAACUwAgAAEeoCAAC+TAIAAP8xg Date: Mon, 31 Mar 2014 23:28:46 +0000 Message-ID: <11cb993ca9e2479aa29b44d443ba438a@SN2PR03MB080.namprd03.prod.outlook.com> References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> <53397F7C.2060603@mykolab.com> <53398AB3.9090102@gmail.com> <4564B6F0-EAE8-457F-8698-ED929F4DDA01@pahtak.org> <26D8EEDC-DE7D-4681-BE06-216DBAF55BEE@vigilsec.com> In-Reply-To: <26D8EEDC-DE7D-4681-BE06-216DBAF55BEE@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-forefront-prvs: 0167DB5752 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(199002)(189002)(243025003)(76482001)(92566001)(90146001)(95666003)(80022001)(98676001)(93516002)(94946001)(15202345003)(54316002)(19580395003)(33646001)(65816001)(97186001)(86612001)(46102001)(77096001)(95416001)(56816005)(47736001)(50986001)(76786001)(76576001)(79102001)(85306002)(99286001)(74316001)(93136001)(85852003)(54356001)(20776003)(80976001)(69226001)(74662001)(77982001)(81542001)(53806001)(2656002)(87936001)(74502001)(81686001)(4396001)(74876001)(31966008)(87266001)(94316002)(59766001)(81816001)(86362001)(47976001)(81342001)(83322001)(63696002)(47446002)(56776001)(83072002)(97336001)(15975445006)(76796001)(74706001)(51856001)(74366001)(49866001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB079; H:SN2PR03MB080.namprd03.prod.outlook.com; FPR:7C1CF154.2DCA130A.3DF5BF3B.D6E5FE41.2035E; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ke5Xw_qKUhOjl3Hk1mBe4lBNaR0 Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Mar 2014 23:28:55 -0000 -----Original Message----- From: Russ Housley > Recall that a predictable random number generator was discovered in the D= ebian release > about this time [1]. It is rather scary that it took so many months for = this flaw to be > noticed after it was released in September 2006; the problem was not rep= orted until > May 2008. In this context, I was interested in getting as enough qualit= y bits from the > good random source into the calculation of the session values to overcom= e the poor > contribution from the other side. It's the old difficult distinction between 'entropy' and 'pseudorandomness'= . IIRC, the Debian bug put a ceiling of only 15 bits of entropy, ever, for th= e entire process. So it was too broken to really matter there. But Dual EC = is an example of a PRNG with a feature where observing more bits makes life= easier for an attacker who knows the backdoor key. Is there another mainst= ream example since 64-bit block ciphers? The short 96-bit Finished message data in TLS is an example of the design l= imiting the number of bits which emerge from a PRNG. The only explanation I= can see for it being so short is that someone didn't want to emit near as = much output as there was entropy going into the master secret. If there is an invisible hand at work here (across the decades) it is eithe= r schizophrenic or wants us to believe so. > If a random number > generator with a backdoor was raised back then, I'm not sure it would hav= e gotten the same > attention as today. I think you may be right. http://rump2007.cr.yp.to/15-shumow.pdf On the Possibility of a Back Door=20 in the NIST SP800-90 Dual Ec Prng=20 Dan Shumow, Niels Ferguson, Microsoft Schneier even had a whole article about it in Wired, but the link seems bro= ken now. http://www.wired.com/politics/security/commentary/securitymatters/2007/11/s= ecuritymatters_1115 - Marsh My own personal opinions, usual disclaimers apply. From nobody Mon Mar 31 17:31:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFDC1A6F7A for ; Mon, 31 Mar 2014 17:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 wOmGLMuCJeTw for ; Mon, 31 Mar 2014 17:31:49 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 38FC91A6F76 for ; Mon, 31 Mar 2014 17:31:49 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id E26152005D902 for ; Mon, 31 Mar 2014 17:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=v4Si+1Avlm+zBV55Or1M 29KGtHw=; b=v9S58r8FubBOT5JkwZXu5Ii+yTPX1acMP+RIn1Mnn58LIll5wUTr xQ69DEIC2oKF8tp6inWQhcFWQoPYmyiKqa+99We55Fx1F/jxCAImUOeRzPBYwT52 Xr/PNhOkgVr94MpmgxpfqQAAFr7+993w3I3iDL/R2z/BLxfak7zDBLQ= Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id 97C932005D901 for ; Mon, 31 Mar 2014 17:31:45 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so5565540wes.1 for ; Mon, 31 Mar 2014 17:31:44 -0700 (PDT) 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=lWFCakgT7NNrSygqGt61VQNvfi1y5Yg8bdn06ilVdUk=; b=UJsZ8AWlR3zz5f5tHQoIAHbpQXSIkL1ChZOoYNkvewsarpmcgZ+cx95UyoaBGyJwuO KotN80wdxBEZkIcVMwXrcFCZ/FGPMRhKXeL33o7GWTQTL6vjnq6X6itkqt30926syjmb TBtn/6A2kyea8Xet/i1aIGCoIYh762PD5PtCnR5Y1DdhopNH7iAItJMNj6CypYXbeK0W 88mQ/asxPzdgFwZlQ9PvPydlUL3lfkGhm0PUTz14GDX3S307Owgqdnabl/cmyeS3wCYc YFAPEf+5HaN/Y9SDwt2WOEfQf+RT3vjwam13+k9wzslwxG7TkyKBJTnK0yVuGNgysM2y JLsw== MIME-Version: 1.0 X-Received: by 10.194.174.42 with SMTP id bp10mr9488640wjc.57.1396312304424; Mon, 31 Mar 2014 17:31:44 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Mon, 31 Mar 2014 17:31:44 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 Mar 2014 19:31:44 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5-o3FkuWRZmqYBENj3VFLueI-4Q Cc: "tls@ietf.org" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2014 00:31:50 -0000 If this is in reference to Dual_EC, well, TLS has always had enough bytes of nonce to exploit the conjectured Dual_EC backdoor (assuming one did not feel forced to send the 32 bits of Unix time, which, indeed, some libraries _don't_). The Reuters article doesn't provide a real source, just a source of speculation, so it's hard to say. It seems like a plausible attack because of the 32-bit Unix time, and because the normal 32-byte nonces might not be a contiguous 32-byte output of Dual_EC. And because there was no pressing need for extra entropy. Note that even if this really was the intention of RSA/NSA at the time, EKR might not have known it. Nico -- From nobody Mon Mar 31 17:35:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93CB1A6F76 for ; Mon, 31 Mar 2014 17:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 2fxKUkLntX2l for ; Mon, 31 Mar 2014 17:35:55 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id A7D761A08B4 for ; Mon, 31 Mar 2014 17:35:55 -0700 (PDT) Received: (qmail 22525 invoked by uid 0); 1 Apr 2014 00:35:52 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 1 Apr 2014 00:35:52 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id kQbi1n0022UhLwi01QblSJ; Mon, 31 Mar 2014 18:35:51 -0600 X-Authority-Analysis: v=2.1 cv=QsvNgzCd c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=4eyjf-e663kA:10 a=ek430v7sx0sA:10 a=3NT3xRclEPMA:10 a=8nJEP1OIZ-IA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=F1f4aVYuAAAA:8 a=cMLUUAMYAAAA:8 a=q7Tenriqb_UJuotXslAA:9 a=wPNLvfGTeEIA:10 a=XKWEBOc0IU4A:10 a=tpyqGl1enTcA:10 a=5luCnA0kHHkA:10 a=9BG51CMlzAsA:10 a=S4hkHOiWPWUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=rig4t7GbzabjOUm93KUxQlyA+snKYI0cXeH9tT4eki8=; b=hw5VIkJjEaOqe3m9BfAi5DdOP63tWaTPcaGw9o1+5c0innZQujTRu5PtF4d3rfmdiF8pCvGV2W4pfxtC+gicSoHhKGBPOEPC29cAKSwTG2VEJa65+PFSFabCue2bilZb; Received: from [24.6.98.54] (port=43675 helo=[192.168.11.13]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WUmg2-0001hW-Re for tls@ietf.org; Mon, 31 Mar 2014 18:35:42 -0600 Message-ID: <533A09DC.5060303@KingsMountain.com> Date: Mon, 31 Mar 2014 17:35:40 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: IETF TLS WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.6.98.54 authed with jeff.hodges+kingsmountain.com} Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WuCoOR5HX_l4dLPSUtHw0KMRQHA Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2014 00:35:57 -0000 >> Schneier even had a whole article about it in Wired, but the link seems >> broken now. >> >> http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115 The Strange Story of Dual_EC_DRBG https://www.schneier.com/crypto-gram-0711.html#10 =JeffH From nobody Mon Mar 31 17:46:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8377C1A6F5D for ; Mon, 31 Mar 2014 17:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 oBBV37XcNqZA for ; Mon, 31 Mar 2014 17:46:16 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 79E8E1A6F11 for ; Mon, 31 Mar 2014 17:46:16 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 01AD7674058 for ; Mon, 31 Mar 2014 17:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=qo8YBI8ajDBgHIvxXzC/ K9AdHLA=; b=Ye+72lMCRXSnMw1T90Wrp7PU9rMlT298f7FGVK6sUN9WdN+yLvx3 Wz/hSUvNYqlFOv2bI46Glr3KqW2IBCJtWOfSCT2Yne25w35ZCMFrkMoZspLe85en fuR+JZMzDVYccanU6zBH2W4AJNGYQgvZFvhQLlnOFAHMWOSlilNe/tM= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id AAE63674056 for ; Mon, 31 Mar 2014 17:46:12 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p61so5600109wes.27 for ; Mon, 31 Mar 2014 17:46:11 -0700 (PDT) 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=494ne1p2N2Mu7inEVv6EAodjKXF2a81b2SSMz0nnPdo=; b=aIEKrWcjsq4jJrUc44DSDgd+n6nXP9FxdxWKfFpO5TuK6il7CgUsQxk5Ty1yTraJQA wtA/ZbBDTRYkaFtakfEePuPKQHyBiitSvuS0N4gt4RHZaWAjPR51+wT1wpidteKA1Khk 1ceGqR196hrGm+Yv84bDnZQXGpbah/S9L5YqQkIV+lbcgnZtcbzfq6gamekoyclfW0Ty mn2HLjG29crLqqFJDZzMJI3dNbcMF+higW/tgRAc10kADAzs9BVCAR0yafsmLAkukbmc 4mdDwcPt50Y12ZCW00/L+tpyibe3QDsT1WhK5+lZWbU3w9J/oDih1Bc1FhgNWMt0HNiN 2PSg== MIME-Version: 1.0 X-Received: by 10.180.12.147 with SMTP id y19mr11622359wib.39.1396313171256; Mon, 31 Mar 2014 17:46:11 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Mon, 31 Mar 2014 17:46:11 -0700 (PDT) In-Reply-To: <26D8EEDC-DE7D-4681-BE06-216DBAF55BEE@vigilsec.com> References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> <53397F7C.2060603@mykolab.com> <53398AB3.9090102@gmail.com> <4564B6F0-EAE8-457F-8698-ED929F4DDA01@pahtak.org> <26D8EEDC-DE7D-4681-BE06-216DBAF55BEE@vigilsec.com> Date: Mon, 31 Mar 2014 19:46:11 -0500 Message-ID: From: Nico Williams To: Russ Housley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hBf0mJkXZfHpuT5-zEsmeHxVQu4 Cc: IETF TLS Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2014 00:46:19 -0000 On Mon, Mar 31, 2014 at 2:12 PM, Russ Housley wrote: > [...] Under no circumstance does sending more nonce bits help palliate a weak RNG. On the contrary, doing so can only make the sender more susceptible to attack. In 2006 we would all have understood this. Now, the I-D in question are very explicit as to motivation: The United States Department of Defense has requested a TLS mode which allows the use of longer public randomness values for use with high security level cipher suites like those specified in Suite B [I-D.rescorla-tls-suiteb]. The rationale for this as stated by DoD is that the public randomness for each side should be at least twice as long as the security level for cryptographic parity, which makes the 224 bits of randomness provided by the current TLS random values insufficient. That's not likely to have raised eyebrows much in 2006 -- that is true. Even with knowledge of backdoored RNG designs it might not now (because that's a local problem now as ever). (If we were to always use ECDHE then the nonces could be sent encrypted in the ECDHE shared secret. This wouldn't prevent either party from using the nonce payload as a covert channel though, and neither party can do anything to preclude the other from leaking state in-band via their nonces, encrypted or otherwise, much less out of band.) Nico -- From nobody Mon Mar 31 18:51:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3A61A6F81 for ; Mon, 31 Mar 2014 18:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Endl5VMTlSb for ; Mon, 31 Mar 2014 18:51:27 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id E344C1A6F20 for ; Mon, 31 Mar 2014 18:51:25 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id DC2FF118BF; Mon, 31 Mar 2014 21:51:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=4pUuNEzFvxW+ 5uDHto1cKLYF0BU=; b=chMB4FJu4P/Yhc9ixZc7Af0IJe6WhLDtOnyeM1nFSPYv nGuV8bxPPNLGlgcKWH2uS7EUD4atqJMYPj+s7IfmMRfKaELioQikjBjs6a3+oX8/ XjZuW2oJuBrZuK5Iokf52Ihx1UQ4dIwx37xewPvjX45XvWkSHxhrzJXXIOXWUwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=qCGjL/ vgvD+wNAVZnYKafwdve+4iunGU2zcBNXehLxFIzRYT4KgeZqg+GbawCQlKBx3GYz uNLUOhJDzq/V2jEdh7ojb3uAewmPAfNJ7bXuTqJrrQRX8vSA+40rKxRDXs9VKdqS 360DX2IpIGBXErVIftTJ7rw9Dgnp8GAzZ3Ztk= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D2C20118BE; Mon, 31 Mar 2014 21:51:21 -0400 (EDT) Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id CE321118BD; Mon, 31 Mar 2014 21:51:20 -0400 (EDT) Message-ID: <533A1B97.5060203@pobox.com> Date: Mon, 31 Mar 2014 18:51:19 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 1FA50EBC-B940-11E3-BA69-873F0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/N3W9zi_zEtPiHUclnzFRZDOX9yc Cc: "tls@ietf.org" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2014 01:51:28 -0000 Nico Williams wrote: > If this is in reference to Dual_EC, well, TLS has always had enough > bytes of nonce to exploit the conjectured Dual_EC backdoor (assuming > one did not feel forced to send the 32 bits of Unix time, which, > indeed, some libraries _don't_). Would a mitigation be to take 64 bytes of DRBG output, run it through SHA-256 and use the result as the 32-byte (client|server) random? Mike From nobody Mon Mar 31 19:03:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760001A6F79 for ; Mon, 31 Mar 2014 19:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p87zB1cPI6B for ; Mon, 31 Mar 2014 19:03:02 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E61671A0905 for ; Mon, 31 Mar 2014 19:03:01 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id q9so6876736ykb.2 for ; Mon, 31 Mar 2014 19:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BLxaNLQsMCDqHFNwKXywpn8J44BqR256fOCKlyP+JwA=; b=Jx+oV3heQcQXURu6KQ/aLw4DW+ilBzRxwK40oj7aEVIXiDkiSOYS8EIHBPfMQQUqF7 BMpmBcMs/snj0x+Ogs6TK76gYKKCqPgPDYG04kgnsWgok7sWSKqQJ8YCXkDpuSaswTPs 7cHj58V8flNkLnE9N11hZhoKwv5kjyc78vyNEVkffBrbrNMyMa1beZ12U0qt4b7Yh2X3 VM2eGuJ/wR1TfwXc8GZJDXAtjF114SVCmCRa8xfd70c0oKK2jy5K/qEj45asB7mEQl03 AAwRHIFu0gmP6SLzoYtUwW5UiZJpUvIR/LXzUPbcD4GtWvXcN5habR6bc4YsrfSsddFp 91Yg== MIME-Version: 1.0 X-Received: by 10.236.133.37 with SMTP id p25mr6690303yhi.112.1396317778352; Mon, 31 Mar 2014 19:02:58 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 31 Mar 2014 19:02:58 -0700 (PDT) In-Reply-To: References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> <53397F7C.2060603@mykolab.com> <53398AB3.9090102@gmail.com> <4564B6F0-EAE8-457F-8698-ED929F4DDA01@pahtak.org> <26D8EEDC-DE7D-4681-BE06-216DBAF55BEE@vigilsec.com> Date: Mon, 31 Mar 2014 19:02:58 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AkWXd1i6wEHzS3_jq1EqU0RS7uc Cc: IETF TLS Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2014 02:03:03 -0000 On Mon, Mar 31, 2014 at 5:46 PM, Nico Williams wrote: > On Mon, Mar 31, 2014 at 2:12 PM, Russ Housley wrote: >> [...] > > Under no circumstance does sending more nonce bits help palliate a > weak RNG. On the contrary, doing so can only make the sender more > susceptible to attack. In 2006 we would all have understood this. That's why these remained I-Ds. > > Now, the I-D in question are very explicit as to motivation: > > The United States Department of Defense has requested a TLS mode > which allows the use of longer public randomness values for use with > high security level cipher suites like those specified in Suite B > [I-D.rescorla-tls-suiteb]. The rationale for this as stated by DoD > is that the public randomness for each side should be at least twice > as long as the security level for cryptographic parity, which makes > the 224 bits of randomness provided by the current TLS random values > insufficient. > > That's not likely to have raised eyebrows much in 2006 -- that is > true. Even with knowledge of backdoored RNG designs it might not now > (because that's a local problem now as ever). Huh? Even if the RNG is perfectly fine, I don't see what adding more random information in to the master secret derivation does. That motivation was questioned in 2006 because it doesn't make any sense. The reason server random and client random exist is to avoid replay attacks, and 32 bytes is wildly overkill for this. They don't add anything to the difficulty for an attacker. It's a completely meaningless rationale. The RFC permitting adding extra data into master secret derivation was actually motivated: one would ideally hash identities in, as was discovered very recently. But it doesn't take the extra step of actually fixing the issues, which we still have to do. Sincerely, Watson Ladd > > (If we were to always use ECDHE then the nonces could be sent > encrypted in the ECDHE shared secret. This wouldn't prevent either > party from using the nonce payload as a covert channel though, and > neither party can do anything to preclude the other from leaking state > in-band via their nonces, encrypted or otherwise, much less out of > band.) > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Mar 31 19:21:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7328A1A0914 for ; Mon, 31 Mar 2014 19:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 CmHVG3fI7f9i for ; Mon, 31 Mar 2014 19:21:12 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B309E1A090F for ; Mon, 31 Mar 2014 19:21:12 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 5063C674059 for ; Mon, 31 Mar 2014 19:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=eeDUd9sYYS1o4dr3aO2l CcteLLg=; b=P7hn8N1ampSrL995GS0TknlVBFNZgrIG9jsomPkujKZa6HBklRYX xI3npyVokCyTm6+pTV7Tnff2LY7OuPdpwjLFQc+zug9gIpuCCSRgkeaZq5ukB+MI n65Vc/xeyP5TuRK9kKoTv/D7b2WjbmwbvslZYC/06mhuCUEieq+wc0Y= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 0516D674058 for ; Mon, 31 Mar 2014 19:21:08 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id x48so5638417wes.35 for ; Mon, 31 Mar 2014 19:21:08 -0700 (PDT) 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=vFBfaSkXWvYQL7bd9/uQRYgOywFHGOIS6pZpfNnRrlc=; b=c6P8zz9MnxZnCn1FqD+TJTy9lddZiIxAyhHK0Rj3l+addWFn5YSB1GiiYbJNiR6s/M Gr3gR7uGiVqtxQp8majIRXO2+879/ownrp/0RMZre56f/PYwtd1PnQAUH6MkI8TZqEvd HYY49N24yYhos0zG6Pm0PLZI5TLyxpD1k4sJLBPdbWETYm3+VKhKpE6QEB0BSU7h0wuq nd2O7bSrUG9J5mAnwjSuxpykQXrdJVDU5UC/e5z46HzVROHpkSj2gCgz/9bhLEXO2Qbu 1FUq6ZhZ1TWHYOtsnRBzjLtmyR+wC5o/vtmS50FUwhowu+RG479GrSSeebux22wbDVyU i/Vg== MIME-Version: 1.0 X-Received: by 10.180.12.147 with SMTP id y19mr12026582wib.39.1396318868008; Mon, 31 Mar 2014 19:21:08 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Mon, 31 Mar 2014 19:21:07 -0700 (PDT) In-Reply-To: <533A1B97.5060203@pobox.com> References: <533A1B97.5060203@pobox.com> Date: Mon, 31 Mar 2014 21:21:07 -0500 Message-ID: From: Nico Williams To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Nx86KL5i8iqPP-O21t4tCUgPPwM Cc: "tls@ietf.org" Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2014 02:21:13 -0000 On Mon, Mar 31, 2014 at 8:51 PM, Michael D'Errico wrote: > Nico Williams wrote: >> If this is in reference to Dual_EC, well, TLS has always had enough >> bytes of nonce to exploit the conjectured Dual_EC backdoor (assuming >> one did not feel forced to send the 32 bits of Unix time, which, >> indeed, some libraries _don't_). > > Would a mitigation be to take 64 bytes of DRBG output, run it through > SHA-256 and use the result as the 32-byte (client|server) random? Yes. You don't need 64 bytes either. Just 32, or 24 even, would suffice. The Dual_EC outputs have structure which is needed in order to exploit the putative backdoor. Hashing makes that structure inaccessible to the attacker. Nico -- From nobody Mon Mar 31 19:27:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A4F1A6FC0 for ; Mon, 31 Mar 2014 19:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 ezEXqcJgH5CD for ; Mon, 31 Mar 2014 19:27:01 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 83D441A6F9C for ; Mon, 31 Mar 2014 19:27:01 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 6118259805F for ; Mon, 31 Mar 2014 19:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=JkPNQp4cPbDPa3qITC73 WfmIvZk=; b=gYYXIrO5hqkXvaR/KEOBUXsAwlzuXfBKzJPUGTfJG4HgjS9XJtF9 tw6NwDcXMD3kdvnuXoSxI0XgxRNiSw+UkJ0R/B7tReBW1F2Q50ce9wZFJuPfHIQ3 uvk5DfyV3OWu18drpC5P2akSA2W4OIgqSUcxhUB9tWnTjA6lCv44ywM= Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 11E2A598058 for ; Mon, 31 Mar 2014 19:26:57 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so5464791wes.37 for ; Mon, 31 Mar 2014 19:26:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr16364271wib.39.1396319217056; Mon, 31 Mar 2014 19:26:57 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Mon, 31 Mar 2014 19:26:56 -0700 (PDT) In-Reply-To: References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> <53397F7C.2060603@mykolab.com> <53398AB3.9090102@gmail.com> <4564B6F0-EAE8-457F-8698-ED929F4DDA01@pahtak.org> <26D8EEDC-DE7D-4681-BE06-216DBAF55BEE@vigilsec.com> Date: Mon, 31 Mar 2014 21:26:56 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xjmf-o6zOqHj_Zu08n-WqhT6M_k Cc: IETF TLS Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2014 02:27:02 -0000 On Mon, Mar 31, 2014 at 9:02 PM, Watson Ladd wrote: > On Mon, Mar 31, 2014 at 5:46 PM, Nico Williams wrote: >> On Mon, Mar 31, 2014 at 2:12 PM, Russ Housley wrote: >>> [...] >> >> Under no circumstance does sending more nonce bits help palliate a >> weak RNG. On the contrary, doing so can only make the sender more >> susceptible to attack. In 2006 we would all have understood this. > > That's why these remained I-Ds. I didn't do the necessary list archive-ology. Good to know that my supposition was right. >> Now, the I-D in question are very explicit as to motivation: >> >> The United States Department of Defense has requested a TLS mode >> which allows the use of longer public randomness values for use with >> high security level cipher suites like those specified in Suite B >> [I-D.rescorla-tls-suiteb]. The rationale for this as stated by DoD >> is that the public randomness for each side should be at least twice >> as long as the security level for cryptographic parity, which makes >> the 224 bits of randomness provided by the current TLS random values >> insufficient. >> >> That's not likely to have raised eyebrows much in 2006 -- that is >> true. Even with knowledge of backdoored RNG designs it might not now >> (because that's a local problem now as ever). > > Huh? Even if the RNG is perfectly fine, I don't see what adding more > random information in to the master secret derivation does. That > motivation was questioned in 2006 because it doesn't make any sense. > The reason server random and client random exist is to avoid replay > attacks, and 32 bytes is wildly overkill for this. They don't add > anything to the difficulty for an attacker. It's a completely > meaningless rationale. For me the main problem with sending more nonce bytes is that it increases the bandwidth of a covert channel -- a more general case of making weak RNGs more susceptible to attack. But it seems reasonable _at first glance_ (which is what I meant above) to say that to get X bits of security you need a cipher with X bits of key, PK algorithms with X bits equivalent security, and X bits of nonce from each party. > The RFC permitting adding extra data into master secret derivation was > actually motivated: one would ideally hash identities in, as was > discovered very recently. But it doesn't take the extra step of > actually fixing the issues, which we still have to do. Or channel binding. But one need not send the channel binding data when doing channel binding! Nico -- From nobody Mon Mar 31 19:47:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F39D1A0917 for ; Mon, 31 Mar 2014 19:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 2bGo4WmVnBdJ for ; Mon, 31 Mar 2014 19:47:47 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DFEDC1A0412 for ; Mon, 31 Mar 2014 19:47:47 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id BC124508084 for ; Mon, 31 Mar 2014 19:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=nOo7/QBPytBBsL22PnXn KY3uvO8=; b=MwLS4mrPEz8nsC91/FpLktOiAzBpMBsbmurcLhwbmqVlMdDHkJIN 4XdDT3Cc21sYh7wkNxFZROoLdZ29S2L3MblWKrJNGbZ9F64NV37ZzZTqk4GW9++p e6+qfx7tqCilMds77aADgicuziN0iRNoLonvk/JXt/ZBCLjRzJvfuSo= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 69B9C508072 for ; Mon, 31 Mar 2014 19:47:44 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id x13so6616435wgg.26 for ; Mon, 31 Mar 2014 19:47:43 -0700 (PDT) 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=1iACFD+p2Vqdi5+867O1nS8eoQku8tKPpzFA4T3p4Ao=; b=fychR3cqbbftMwWrF6ng1SpJWQpvYS/JMvrWE30kjRVL8aZsuJiAkI3HQUGz5nxgpK QWZlZgEALeBltmaiobijGJy0XtcA+5pzT4PRRXzouo/iNTIXZXYv2uCqPaNSD9E7z53c 67s8VRgvq1HvJR70Eui2p2GcQxPcg/EKMMZvetnK85pnQAra/zu2EVyujXpRuaxnwN0b PK77R05qcLmEzZN+fQhdGhB4kg5ZNZPHE+HWERQVCW5zhQxDr56SH3Uuo511ccieE/EZ +eIe1LcROR4iBcOpp10L+vZ0Dh9i5aGZCqQ2P+o9GyCYJdaMwrVZ3wjsuU/s+UJtBRkd dFGw== MIME-Version: 1.0 X-Received: by 10.180.97.72 with SMTP id dy8mr16342508wib.5.1396320463336; Mon, 31 Mar 2014 19:47:43 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Mon, 31 Mar 2014 19:47:43 -0700 (PDT) In-Reply-To: References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> <53397F7C.2060603@mykolab.com> <53398AB3.9090102@gmail.com> <4564B6F0-EAE8-457F-8698-ED929F4DDA01@pahtak.org> <26D8EEDC-DE7D-4681-BE06-216DBAF55BEE@vigilsec.com> Date: Mon, 31 Mar 2014 21:47:43 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/C_B2Wvy5P6qnRNb46ohUX4303QI Cc: IETF TLS Subject: Re: [TLS] Extended random is NSA backdoor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2014 02:47:48 -0000 BTW, if the only concern is replay protection then much less entropy will suffice since the birthday paradox is the only real concern then. Coarse timestamps do help increase the value of smaller nonces by allowing the use of a replay cache, but reliable, high-performance replay caching is very difficult to implement correctly. Still, assuming no replay caching I'd say that 28 bytes is overkill indeed.